Artica Meta: SIEM Connector policy

Back to Artica Meta · Artica Meta: Policies

The SIEM Connector policy connects a fleet of Artica nodes to an Artica SIEM from the Meta console.
You no longer generate a certificate bundle on the SIEM and upload it on each node.

Each node sends its events to the SIEM with a client certificate of its own.
The SIEM identifies the node and its tenant by this certificate.
Before this policy, an administrator had to create one bundle per node and per flow in the SIEM console.
They then had to open every node and upload it on the right page.
The policy does all of this for every attached node.

How it works

The SIEM must be a node of Artica Meta itself, with the agent installed.
Meta never calls the SIEM administration API over the network.
It asks the SIEM node through its agent, like any other Meta request.

sequenceDiagram
    participant M as Artica Meta
    participant S as SIEM node (artica-siem)
    participant N as Attached node
    M->>N: Read the status of each flow
    M->>S: Issue a certificate for this node and this flow
    S-->>M: Certificate bundle (kept in memory only)
    M->>N: Policy with the bundle
    N->>N: Install the certificate and connect
    N->>S: Events over mutual TLS

For each attached node and each flow, the SIEM creates a collector and issues its certificate.
Meta forwards the bundle to the node in the same delivery.
Meta never stores it.
It keeps only the public fingerprint of the certificate, so it can deactivate it later.
After that, the node renews its certificate by itself before it expires.

A node that already holds a valid certificate issued by Meta for this SIEM keeps it.
Meta does not issue a new one at each delivery.

Flows

Each flow gets its own collector and its own certificate on the SIEM.
A flow whose service is not installed on a node is skipped on that node.
The delivery status shows it as Service absent.
Meta creates no collector for it.

Requirements

• Artica Meta, and the SIEM node with artica-siem installed and attached to Meta.
• The debian-agent 1.1.98 or later on the SIEM node and on every attached node.
• An articarest version on each node that serves the SIEM Connector policy.

Deploy in this order: Artica Meta first, then the SIEM node, then the attached nodes.
A node with an older agent stays pending.
Its reason says that its agent must be updated.

Create the policy

1. Open Artica Meta > Policies.
2. Click New policy, choose the type SIEM Connector and enter a name.
3. In the Settings tab, fill in the sections described below.
4. In the Targets tab, attach agents or groups of agents.
5. Click Apply.

Nothing is sent before Apply.

SIEM

• SIEM node: click the field, then Check on a node to ask it whether it hosts artica-siem.
  Only the node you check is asked.
  A node that answers No artica-siem cannot be used.
• SIEM address: the name or IP address that the attached nodes use to reach the SIEM.
  Do not add a scheme or a port.
  The field is prefilled with the address Meta knows for the SIEM node.
  Change it when the nodes reach the SIEM through another address, for example behind NAT.
• SIEM tenant: the SIEM tenant where the events of the attached nodes are stored.
  The list comes from the SIEM.

The section also shows the fingerprint of the SIEM certificate authority and the ingest ports.
A port shown as disabled means that this listener is off on the SIEM.
A flow that needs it fails on every node until the listener is enabled.

Flows to connect

Tick the flows to connect: Web proxy, Firewall, Mail, RDS Proxy.
Choose at least one.

Certificates

Certificate validity is the validity requested for each certificate, in days.
Leave it empty to use the SIEM default.
Otherwise enter a value between 7 and 3650.

What happens on the node

On the first delivery, the node installs its certificate for each flow and connects to the SIEM.
It uses the same mechanism as a manual connection.
The flows start right away.

While the policy holds the node, its SIEM pages are read only:

• the SIEM connection of the Web proxy,
• the SIEM connection of the firewall,
• the SIEM connection of the RDS Proxy,
• the SIEM connection of the mail gateway.

A banner says that the connection is managed by Artica Meta.
Connecting, uploading a certificate, changing the target and disconnecting are refused on the node.
The automatic renewal of the certificate keeps running.

If the address of the SIEM changes in the policy, the node reconnects with the certificate it already has.

Detaching a node: leaving the SIEM

Detaching the policy from a node makes the node leave the SIEM.
The same happens when the node leaves a group that carries the policy, or when the policy is deleted.

1. Meta deactivates the node's collectors on the SIEM.
   It does not wait for the node to answer: a node that is offline is cut too.
2. Meta asks the node to disconnect its flows and remove its SIEM certificates.
3. The node lifts the local lock.

Removing one flow from the policy does the same for that flow only.
Moving a node to another SIEM deactivates its collectors on the old SIEM and issues new certificates on the new one.

Collectors are deactivated, not deleted.
Their history stays in the SIEM.
If the SIEM cannot be reached, the deactivation waits and is retried at each pass of the queue.
The Delivery status tab lists the pending deactivations for the provider.

A node that is attached again later gets a new certificate.
Its collector is reactivated on the SIEM.

If the policy can no longer reach a node at all, the local rescue command lifts the lock on the node:

articarest -siemconnector-meta-release

Delivery status

The Delivery status tab shows, for each attached node:

• the state of the delivery and its reason,
• for each flow, the collector name, the certificate expiry date and the state reported by the node (Installed, Service absent, Failed, Not reported).

Common reasons:

Transient failures stay pending and are retried.
A refused content is rejected and waits for a new Apply.

Clusters

Each node of a cluster connects to the SIEM with its own identity.
A slave node receives the policy for itself.
It is not redirected to its master, unlike most other policy types.

SIEM Connector and tenants

The provider can let a customer tenant use a shared SIEM.
Open Artica Meta > SIEM associations and click New association.
Choose the Meta tenant, the SIEM node and the SIEM tenant where its events go.
A Meta tenant has at most one association.

With an association, the customer creates its own SIEM Connector policies.
It can choose the shared SIEM node.
The SIEM tenant is imposed by the association.
The customer never sees the other SIEM tenants or the other associations.

Without an association, a customer can only choose a SIEM node of its own tenant.

The provider keeps full control with its own policies.
For example, it can connect the nodes of some customers to its own SIEM itself.

Removing an association cuts the customer's nodes from that SIEM.
Their collectors are deactivated and the nodes are released.

See Artica Meta: Tenants.

Known limits

• A node cannot move from one SIEM tenant to another by itself.
  The SIEM keeps a collector in the tenant where it was created.
  The delivery is rejected with collector belongs to another SIEM tenant.
  Delete or move the collector on the SIEM first.
• Collector names come from the node host name.
  The firewall, mail and RDS Proxy flows add the suffixes -fw, -mail and -rdp.
  A node already named, for example, proxy-fw would collide with the firewall flow of a node named proxy.
• When a certificate is renewed, the SIEM still accepts the previous one for a short grace period.
• With a validity of 30 days or less, the automatic renewal on the node runs every day.
  Meta then issues a new certificate each day for that flow.
  Prefer a validity above 30 days.
• The mail page of the node is locked by the console only.
  The mail gateway daemon itself has no lock.
• A node controlled by a hostile administrator can renew its own certificate after Meta issued one.
  Meta then cannot deactivate it.
  Treat a node that leaves a tenant as compromised.
• When an association comes back, the nodes that were released are not reconnected automatically.
  Click Apply on their policy.
• If the SIEM node is deleted from Meta, the pending deactivations aimed at it cannot complete.
  Deactivate those collectors by hand on the SIEM.