Skip to main content
 

This document covers what the Assembler is, how it operates, who has access, and how we secure it.

Purpose

The Assembler serves as a network proxy to allow Expel to access security devices on customer-internal networks. These can be traditional physical on-prem networks, or cloud-based networks that function as internal networks.

Do I need an Assembler?

Only if your security devices are "on-prem", either physically, or in a cloud infrastructure logical equivalent. If your security devices are accessible through the Internet, we can access them directly.

Supported Deployment Environments

  • VMWare

  • HyperV

  • Azure

  • AWS

System Components

  • Operating system

    • CentOS 7

  • Open source components

    • Proxying software

      • Envoy

      • Nginx

      • Squid

    • Teleport (SSH access management)

Communications

  • The Assembler doesn't require any inbound access from the internet. The only outbound connection that the assembler needs is for the VPN on TCP port 443 or 8099 to our VPN server (either one is sufficient). The VPN server domain is servicevpn.opsv2.expel.io.

  • The VPN tunnel uses TLS 1.2 with AES-256 encryption.

  • All connections from the assembler into the Expel back end inside the VPN are blocked by the Expel VPN server except teleport.

  • Expel initiates all communication with the Assembler inside the VPN:

    • via HTTPS on port 3128, 8443, and 9500 (for proxying to security devices)

    • via GRPC on port 8500 for configuration of envoy

    • via Teleport on port 3022 (for SSH via Teleport for humans logging in for ad-hoc things)

    • via regular SSH on port 22 (for Ansible configuration management)

  • Communications between Assembler and security tech are dependent on the specifics of each product you have, but generally are outbound from the Assembler. The specifics are covered in the onboarding docs for your device.

  • Inbound SSH is blocked from the customer network to the Assembler. If customer access to the Assembler is required, use the console of your virtualization platform.

  • The Assembler uses DHCP by default. If you prefer, you can use a static IP address.

Credential Management

Credentials for customer devices are never stored on the Assembler. The Expel backend provides the credentials with every job that's run on the Assembler. This is so that if someone physically walks away with the hypervisor on which the Assembler runs, they won't get the creds to your security devices.

How we build it

  • We follow a high-quality, modern software development process for everything that goes on the Assembler, just like we do for our backend software.

  • We sign all the packages (RPMs) being installed on the Assembler.

  • Security testing

    • Internal

      • Lynis

      • Regular security and vulnerability scans

      • Internal risk assessments and pen tests

    • External / third party validation

      • External risk assessment and pen test

How we access it

  • Account structure for assembler access

    • 1 customer account, can only be accessed from virtualization console (no SSH).

    • Expel employees use named accounts. 2FA is required to gain access to log in.

  • Proxy access to security tech

    • Authenticated Expel employees only, 2FA is required.

  • Auditing of events on Assembler

    • All commands issued by Expel analysts on the assembler are audited through teleport. Commands are logged locally on the assembler and logs are exported to central log system.

    • All security device access through proxy is logged using proxy infrastructure and includes URL and Expel analyst that initiated the request. Device access is logged locally to the assembler and can be passed to customer's event logging infrastructure upon request (passed as remote syslog).

  • Engineers only log into the Assembler command line for troubleshooting and onboarding support. No one at Expel SSHs into the Assembler as a routine part of service delivery.

How we maintain it

  • Expel software updates are installed continuously as improvements are made. No customer involvement is needed in this.

  • On a quarterly basis, all assemblers are brought up to the latest patch level for all applications and operating system and rebooted.

  • If critical patches are required, they are performed on an as needed basis.

  • New versions are pushed automatically through Ansible.

  • It should never be necessary to reinstall the assembler from scratch. Expel updates are seamless and don't require customer interaction.

How we harden it

We use Lynis (https://cisofy.com/lynis/), which produces a sort of hardening score. Contact us for the annotated results of our most recent run.

How you can further reduce your risk

Use your network segmentation capabilities (firewalls, and so on) to restrict the Assembler to only being able to access the security devices you want us to access, not everything on your corporate network. See How to provision Expel Assembler for details.