Securing

opscotch was built to operate in the most securely demanding environments and has been designed with many features to increase its security posture. The single most governing principal of opscotch is to "keep the customers data in the customers network".

Given the nature of opscotch, we've taken as many opportunities to prevent data exfiltration that we can think of - please let us know if you find any!

Separation of control

Controlling configuration is split into two different files, with different natures of access.

Bootstrap configuration

The bootstrap configuration is designed to secure sensitive information and service specific data.

The bootstrap configuration:

• is authored by the installer of the opscotch agent.
• is loaded at agent start up and is immutable while the agent is running.
• contents are not accessible by the agent workflow context, except for the Host.data which is accessible from workflow authentication context (this is locked down when in Production mode).
• declares a private key used to decrypt workflow configurations
• refers to a workflow configuration - see below.

Use the bootstrap

Use the bootstrap for sensitive and service/host specific information Do not leak sensitive data into the workflow by using a data property

Workflow configuration

The workflow configuration is designed to have no sensitive information or service specific data.

The workflow configuration:

• is authored by anyone (your team, opscotch consultants, community workflows etc).
• is considered un-trusted.
• is packaged by your team or your opscotch consultants.
• is signed during the packaging stage and will not be loaded by your agent if the signature is not recognised.
• is encrypted during packaging using the agents matching public key - while this is a "public" key, it should be kept private to those authorised to package for your agent.

Keys

Workflow configurations are encrypted using public-private key technology, however in the context of opscotch they should be considered encrypt-decrypt keys - DO NOT SHARE THE PUBLIC/ENCRYPT KEYS

Protect keys

Do not share or reuse your keys. Generate new keys for each agent instance - this prevents mistaken deployments.

Authentication context

The workflow authentication context has elevated access to bootstrap host data, but also has restricted capabilities:

• not permitted to send metrics.
• not permitted to forward to a non-authentication context (step)
• in production mode it is not permitted to log anything.

The authentication workflow is just like any other workflow - you can perform complex flows to complete your required authentication. For example, say you have a service that uses a user name and password. Rather than store the credentials in your bootstrap, you could store the credentials in a remote Key Store (ie Azure key store etc), and perform several stages of HTTP requests to obtain the credentials to use on the service that you want to use.

Use Authentication Processor

Always use Step.authenticationProcessor to perform authentication flows. Use a key store if possible.

Production Mode

The agent is release as two different binaries: Development mode and Production mode. Development mode can not simply be "turned on" - you need to use a different binary.

In production mode:

• Logging is not permitted from authentication context.
• Diagnostic logging is only enabled for a time limited period via diagnostic messaging.
• Workflow flow information is not emitted.

Use Production Mode

Use production mode in production to increase security posture

Access control / internal firewall

Workflow configurations are not trusted, and do not have access to host information.

Workflow configurations request the agent to execute HTTP requests to hosts, however the workflow can not access the host details: it only refers to a name that the configuration gives it.

Host configuration allows the definition of "access control" or "URI firewalls" in the form of regular expressions of allowed URI and HTTP methods - this allows the bootstrap to define which HTTP URI and methods are allowed.

Prior to executing HTTP requests, the agent sanitizes headers to remove known attack vectors.

Use Allow List

Always use Host.allowlist) to define allowed requests

Logging

There are various logging precautions to prevent data exfiltration:

• local logging can be disabled, only using a remote logging platform, or vice-versa.
• log redaction patterns can be used to mask sensitive data.
• hashing can be used to obfuscate raw data
• the audit log will record new metrics, license events, workflow change events, remote logging change events, access attempts to restricted data, flushing of persistence, allow list violations, new headers

Responsible Logging

Only log what is necessary. Use redaction to remove sensitive data.

Vulnerability Scanned

The opscotch code base is scanned frequently and prior to each release for known vulnerabilities using Snyk.

opscotch prides itself on having NO currently known vulnerabilities and makes every attempt to remove or neutralize them.

Please contact us for the current list of known vulnerabilities.

Binary File

The opscotch agent is distributed as a compiled binary file and is extremely difficult to reverse engineer or extract details such as keys from.