Suppose you need to perform a security assessment of an SD-WAN solution. There are several reasons for this and one of them is selecting an SD-WAN provider or product.
A traditional SD-WAN system involves many planes, technologies, mechanisms, services, protocols and features. It has distributed and multilayered architecture. So where should you start?
This document follows JP Aumasson's approach described in a series of auditing crypto articles ([1], [2]).
The main goal of this document is to list basic sanity checks that can be used when investigating SD-WAN. We will consider general checks that can be applied to any SD-WAN system.
- What third-party components and libraries are used? How secure are these? Are the components using their latest versions?
- Run lynis tool on each node and assess hardening level.
- Run a host-based vulnerability scanner (vulners, LibScanner, etc.) and assess patch management level.
- Run a web vulnerability scanner (e.g.,
Burp Suite
,Acunetix
, etc.) against a web management interface.
- Is a vendor-controlled cloud management interface used within the architecture?
- How does a network device get its initial configuration?
- How does a network device discover a controller, orchestrator and other entities?
- How do network devices, the controller and the orchestrator authenticate each other?
- How trust is provisioned and what mechanisms are used? One-time tokens, X.509 certificates, login and password, pre-shared keys?
- How do re-discovering or re-joining mechanisms work?
- Which cryptographic protocols and implementations are used on the dataplane?
- Which cryptographic protocols and implementations are used on the controlplane?
- Are AEAD ciphers supported?
- How key management is implemented?
- How consistent are the security levels of the various protocols and primitives?
- Look for legacy primitives like DES, TripleDES, RC4, MD5, SHA1 or custom primitives.
- Is it possible to control cryptographic mechanisms (e.g., enable TLS 1.3 only, disable unwanted ciphers, etc.)?
- Run a TLS scanner (e.g.,
testssl.sh
, SSL Labs server scanner,sslyze
, etc.) against TLS-enabled interfaces and assess the results. - Run an SSH scanner (e.g.,
ssh_scan
) against SSH-enabled interfaces. - Which type of PKI is used? Public or private?
- Which protocols are used between orchestrator, controller, and edge devices? Are they secured?
- How SD-WAN entities do authenticate each other?
- Run WireShark on each node (orchestrator, controller, edge router), review traffic and check whether unencrypted sensitive packets are sent.
- Do the chosen protocols and primitives provide the security required by your threat model?
- Is RSA key exchange used?
- Where and how secrets (e.g., private keys, pre-shared keys, tokens) are stored?
- Check whether the same hardcoded certificate is used on different deployments.
- Is a key renewal mechanism supported on control channels?
- Check protection mechanisms against CSRF attacks.
- Check HTTPS supporting and web hardening mechanisms: secure headers, content-security policy, CORS headers.
- Test all HTTP services against Slow HTTP DoS attacks.
- Are cryptography secrets accessible via the Web interface?