Siren Platform User Guide

Authentication and access control

Siren Investigate can be integrated with Elasticsearch clusters protected by either Search Guard or Elastic X-Pack.

In this scenario, both Siren Investigate and Gremlin Server (the backend component used by the graph browser visualization) must be configured to serve requests over HTTPS.

Starting with version 10.1, the Siren platform includes Search Guard Compliance Edition to help you to stay compliant with regulations including GDPR, HIPAA, SOX and ISO.

The following shows a simplified representation of the invocation chain with Siren Federate and the audit and compliance modules.

peaky_revised.png

Siren invocation chain

Enabling HTTPS in Siren Investigate

You should protect your Siren Investigate installation by using a reverse proxy. Some example configurations follow, but other reverse proxies may also be used.

Using NginX as a reverse proxy with HTTPS (Linux)

Add the following virtual server to your configuration: Here we assume letsencrypt has been used to provide the certificate.

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    server_name siren.example.com;

    root /var/www/html;
    index index.html index.htm;

    ssl_certificate /etc/letsencrypt/live/siren.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/siren.example.com/privkey.pem;

    access_log /var/log/nginx/siren-ssl.access.log;
    error_log /var/log/nginx/siren-ssl.error.log error;

    include snippets/ssl-params.conf;

    location / {
        proxy_pass http://127.0.0.1:5606;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection 'upgrade';
        proxy_set_header Host $host;
        proxy_cache_bypass $http_upgrade;
    }
}

In /etc/nginx/snippets/ssl-params.conf configure:

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;
ssl_ciphers "EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH";
ssl_ecdh_curve secp384r1;
ssl_session_cache shared:SSL:10m;
#ssl_session_tickets off;
ssl_stapling on;
ssl_stapling_verify on;
resolver 8.8.8.8 8.8.4.4 valid=300s;
resolver_timeout 5s;
# Disable preloading HSTS for now. You can use the commented out header line that includes
# the "preload" directive if you understand the implications.
# Also do not include subdomains by default
#add_header Strict-Transport-Security "max-age=63072000; includeSubdomains; preload";
add_header Strict-Transport-Security "max-age=63072000";
add_header X-Frame-Options DENY;
add_header X-Content-Type-Options nosniff;
ssl_dhparam /etc/ssl/certs/dhparam.pem;

The SSL configuration in ssl-params.conf can be shared among multiple virtual servers.

Now generate a unique set of Diffie-Helman parameters (this mitigates the LOGJAM vulnerability):

openssl dhparam 2048 -out /etc/ssl/certs/dhparam.pem

Note that this constitutes a MINIMUM RECOMMENDED LEVEL of security. Your installation’s requirements may be more stringent.

Using Apache as a reverse proxy with HTTPS (Linux)

Add the following virtual host to your configuration. Here we assume letsencrypt has been used to provide the certificate.

<VirtualHost *:443>
    ServerName siren.example.com
    DocumentRoot /var/www/html
    DirectoryIndex index.html index.htm

    CustomLog /var/log/apache2/siren-ssl.access.log combined
    ErrorLog /var/log/apache2/siren-ssl.error.log

    SSLEngine on
    SSLStrictSNIVHostCheck off
    SSLCertificateFile /etc/letsencrypt/live/siren.example.com/fullchain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/siren.example.com/privkey.pem
    SSLCACertificateFile /etc/letsencrypt/live/siren.example.com/chain.pem

    <location / >
        ProxyPass http://127.0.0.1:5606
        ProxyPassReverse http://127.0.0.1:5606
    </Location>
</VirtualHost>

Now configure /etc/apache2/conf.d/security.conf:

Header unset X-Powered-By
Header set X-Frame-Options: "sameorigin"
Header set X-Content-Type-Options: "nosniff"
TraceEnable Off
ServerTokens Prod
ServerSignature Off

And /etc/apache2/mods-available/ssl.conf:

<IfModule mod_ssl.c>

SSLRandomSeed startup builtin
SSLRandomSeed startup file:/dev/urandom 512
SSLRandomSeed connect builtin
SSLRandomSeed connect file:/dev/urandom 512

AddType application/x-x509-ca-cert .crt
AddType application/x-pkcs7-crl	.crl

SSLPassPhraseDialog  exec:/usr/share/apache2/ask-for-passphrase
SSLSessionCache		shmcb:${APACHE_RUN_DIR}/ssl_scache(512000)
SSLSessionCacheTimeout  300

SSLProtocol all -SSLv2 -SSLv3
SSLHonorCipherOrder on
SSLCipherSuite \
  "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 \
  EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 \
  EECDH EDH+aRSA !3DES \
  !aNULL !eNULL !LOW !MD5 !EXP !PSK !SRP !KRB5 !DSS !RC4 !DES"
SSLCompression off

## Strict Transport Security
Header set Strict-Transport-Security "max-age=15768000"

## Apache 2.4 only
SSLUseStapling on
SSLStaplingResponderTimeout 5
SSLStaplingReturnResponderErrors off
SSLStaplingCache shmcb:/var/run/ocsp(128000)

## Apache >=2.4.8 + OpenSSL >=1.0.2 only
SSLOpenSSLConfCmd DHParameters /etc/ssl/certs/dhparam.pem

</IfModule>

You must enable mod_headers for the SSL security settings to take effect.

Now generate a unique set of Diffie-Helman parameters (this mitigates the LOGJAM vulnerability):

openssl dhparam 2048 -out /etc/ssl/certs/dhparam.pem

Note that this constitutes a MINIMUM RECOMMENDED LEVEL of security. Your installation’s requirements may be more stringent.

Native SSL support

While you should always run Siren Investigate behind an SSL reverse proxy, it is sometimes necessary to also enable SSL support on the Siren Investigate server itself - for example, when the reverse proxy is an appliance, or is installed on a separate server.

Native SSL support can be enabled by copying the certificate and key files to a location readable by the Siren Investigate process and setting the following parameters in config/investigate.yml:

  • server.ssl.enabled: set to true to enable SSL.
  • server.ssl.certificate: path to a certificate.
  • server.ssl.key: path to the certificate key.
  • server.ssl.keyPassphrase: the passphrase of the certificate key; if the key is not encrypted the parameter can be omitted.

The certificate and key files must be PEM encoded.

For example:

server.ssl.enabled: true
server.ssl.certificate: "pki/server.crt"
server.ssl.key: "pki/server.key"

The Siren Investigate demonstration distribution includes a sample certificate and key in the pki folder.

For additional SSL settings, see Configuring Siren Investigate.

Enabling HTTPS in Gremlin Server

HTTPS must be enabled in Gremlin Server to secure requests from Siren Investigate, even if Siren Investigate is configured behind a reverse SSL proxy.

To enable HTTPS in the Gremlin Server, set the following parameters in the investigate_core.gremlin_server section of the config/investigate.yml file:

  • url: The URL of the Gremlin Server endpoint; ensure that the protocol is set to https.
  • ssl.key_store: The path to the Gremlin Server certificate in Java KeyStore format.
  • ssl.key_store_password: The password of the Gremlin Server certificate keystore.
  • ssl.ca: The path of the certification authority chain bundle that can be used to validate requests from Siren Investigate to the Gremlin API; you can omit this parameter if the certificates for the Siren Investigate HTTPS interface have been issued and signed by a public authority.

For example:

investigate_core:
  gremlin_server:
    url: https://127.0.0.1:8061
    ssl:
      key_store: "pki/gremlin.jks"
      key_store_password: "password"
      ca: "pki/cacert.pem"

After restarting Siren Investigate, click Settings, then click Datasources, and ensure that the URL of the Siren Investigate Gremlin Server datasource is equal to the URL set in investigate.yml.

The Siren Investigate demonstration distribution includes a sample key store and CA bundle in the pki folder.