Havainnoitavuus

Suoratoista kaikki tapahtumat SIEM:iin, allekirjoitettuina ja todennettavina.

Auditointi- ja tietoturvatapahtumat lähetetään reaaliajassa Splunkiin, Datadogiin, Elasticiin, Microsoft Sentineliin, S3 WORM -tallennukseen, tavalliseen syslogiin tai yleiseen HTTPS-webhookiin (Enterprise-paketti). Jokainen tapahtuma kantaa auditointirivin Ed25519-allekirjoituksen ja sen tehneen avaimen id:n; yrityksen julkinen avain julkaistaan osoitteessa /audit/pubkey/:company_id. Epäonnistuneet toimitukset yritetään uudelleen kasvavalla viiveellä jopa vuorokauden ajan, minkä jälkeen ne siirtyvät kuolleiden viestien jonoon, josta voit toistaa ne.

Caldyr

Splunk

Datadog

Elastic

Sentinel

S3 WORM

Syslog

Miten se toimii

Tapahtuma lähetetään

Auditointirivi allekirjoitetaan ja lähetetään SIEM-lähetyspalveluun.

Allekirjoituslohko liitetään

Kirjekuori on auditointirivi ja sen allekirjoituslohko: sig, key_id, pubkey_fp, prev_hash, payload_hash. Yksi allekirjoitusavain yritystä kohden, ei kohdetta kohden.

Lähetetään kohteeseesi

Kuusi todennustapaa kohdetta kohti - none, bearer, mTLS, signed JWT, Sentinel OAuth2 ja Sentinel shared key - ja kohde, joka ei määritä tapaa, saa none. mTLS ja signed JWT eivät lähetä jaettua salaisuutta; bearer lähettää kohteen oman tunnuksen joka lähetyksessä, Sentinel OAuth2 Azure AD:n käyttöoikeustunnuksen, Sentinel shared key työtilan avaimesta johdetun HMAC:n, ja Splunk ja Datadog lähettävät tunnuksensa myös mTLS:n alla. HTTP-kohteet vaativat https:// ja syslog TCP:n yli vaatii TLS:n, mutta syslog UDP:n yli on salaamaton.

Toisto uudelleenyhdistämisessä

Epäonnistuneet toimitukset yritetään uudelleen kasvavalla viiveellä jopa 24 tuntia, minkä jälkeen ne siirtyvät kuolleiden viestien jonoon, josta voit toistaa ne.

Syväsukellukset

Allekirjoitetut kirjekuoret

Lohko on Ed25519-allekirjoitus auditointirivistä sellaisena kuin se on tallennettu, ketjutettuna edelliseen riviin: sig, key_id, pubkey_fp, prev_hash, payload_hash. raw_json, ECS, OCSF ja syslog kantavat kaikki viisi; CEF ja LEEF kantavat vain allekirjoituksen ja avaimen id:n. Yrityksen julkinen avain julkaistaan osoitteessa /audit/pubkey/:company_id, emmekä toimita todentajaa teidän päähän: lohkon tarkistaminen on SIEM:in tehtävä. Kohteessa, jolla on suodatinmuunnoksia, allekirjoitus kattaa rivin sellaisena kuin se oli ennen muunnosta.

Toimitustakuut

Vähintään kerran idempotentein tunnistein. Epäonnistuneet erät yritetään uudelleen kasvavalla viiveellä; viimeisen yrityksen jälkeen tai pysyvän hylkäyksen sattuessa ne siirtyvät kuolleiden viestien jonoon, josta toistat ne käsin.

WORM- ja vaatimustenmukaisuuskohteet

S3 Object Lock governance- tai compliance-tilassa muuttumatonta tallennusta varten: auditoijat saavat säilytystodisteen suoraan.

Määritä kohde

shell · curl

# 1. store each credential, get back a handle (company admin) $ curl -X POST $CALDYR_URL/api/siem/secret-bindings \ -H "Authorization: Bearer $CALDYR_TOKEN" -H "Content-Type: application/json" \ -d '{"team_id": "<your-team-uuid>", "field": "mtls_cert_ref", "value": '"$(jq -Rs . < client.pem)"'}' # → 201 {"handle": "<32 hex>", "ref": "vault-ref://h/<32 hex>", …} # value is a PEM file, JSON-escaped by jq; repeat with field mtls_key_ref (key PEM) and mtls_bearer_ref (Splunk HEC token) # 2. create the destination, referencing the returned refs $ curl -X POST $CALDYR_URL/api/siem/destinations \ -H "Authorization: Bearer $CALDYR_TOKEN" -H "Content-Type: application/json" \ -d '{"name": "splunk-prod", "kind": "splunk_hec", "url": "https://splunk.example.com:8088", "format": "ecs", "batch_size": 100, "auth_kind": "mtls", "config": { "mtls_cert_ref": "vault-ref://h/<cert handle>", "mtls_key_ref": "vault-ref://h/<key handle>", "mtls_bearer_ref": "vault-ref://h/<token handle>"}}'

SIEM on totuuden lähde - me vain syötämme sitä, allekirjoitettuna.

Kun tietoturvaloukkausta aletaan selvittää, auditoija käyttää yrityksen omia allekirjoitettuja tietueita, ei meidän. Me olemme vain kuriiri.

Vertailu

	Caldyr	Webhookit (allekirjoittamattomat)	Manuaalinen lokivienti
Reaaliaikainen toimitus	push · none, bearer, mTLS, JWT tai Sentinel	allekirjoittamaton POST	vain erissä
Allekirjoitetut kirjekuoret	Ed25519-lohko · yrityksen avain	ei	ei
Toisto uudelleenyhdistämisessä	pysyvä puskuri	pudotetaan vikaantuessa	ei sovellu
Useita kohteita	kaikki samanaikaisesti	yksi URL	manuaalisesti
WORM-vaatimustenmukaisuus	S3 Object Lock	ei	ei

UKK

Mitä jos SIEM:ini on offline-tilassa?

Epäonnistuneet toimitukset yritetään uudelleen kasvavalla viiveellä ja siirretään sitten kuolleiden viestien jonoon, josta voit toistaa ne. Hallintataso jatkaa toimintaansa.

Voinko lähettää useisiin kohteisiin samanaikaisesti?

Kyllä. Yleinen kokoonpano on Splunk SOC:lle, S3 WORM vaatimustenmukaisuudelle ja Datadog kehitykselle, kaikki samasta tapahtumavirrasta itsenäisin suodatussäännöin.

Mikä on tapahtuman muoto?

raw_json oletuksena; ECS, CEF, LEEF, syslog ja OCSF -variantit ovat saatavilla kohdekohtaisesti, sekä mukautetut kenttäkartoitukset YAML-muunnoksella.

Voinko sensuroida arkaluontoisia kenttiä?

Kohdekohtaiset suodatussäännöt tukevat jsonpath-sensurointia. PII-kentät voidaan poistaa ennen kuin ne saavuttavat matalamman luottamuksen kohteet.

Valmis hallitsemaan tekoäly-infrastruktuuria?

Pyydä pääsyä minuuteissa, tai kerro meille air-gap-käyttöönotosta.

Aloita