Many SD-WAN vendors in the marketplace today offer the promise of “simple” or “easy” SD-WAN deployment — all packaged with a rich set of features that enterprises can’t live without.
Yet all too often, “simplicity” comes at the expense of security. What’s more, this tradeoff is often made without the explicit knowledge or consent of customers and end-users, for whom security in the SD-WAN environment is of the utmost importance.
At CloudGenix, we take the security of our implementation extremely seriously, while making sure the complexities of doing so are transparent to the end customer or end-user. As a customer, you should never accept anything less from a vendor than the highest levels of security, transparency, and service — marketing claims notwithstanding. As leaders in best-practice security for SD-WAN, we wanted to share some of the security features at CloudGenix that help set us — and any — vendor apart:
Zero Touch Provisioning
CloudGenix uses a combination of Manufacturer Installed Certificates (MICs) and Customer Installed Certificates (CICs) as part of the provisioning process, over a secured SSL channel. A MIC is a certificate installed/created by CloudGenix for a device at the time of manufacturing, and a CIC is a certificate created for a Customer Tenant at the time a device is claimed/provisioned.
Without Zero Touch Provisioning, it is impossible to guarantee that rogue devices will not join an SDWAN fabric and access each part of the environment that becomes exposed.
By utilizing the certificate process and SSL to onboard devices throughout the provisioning process, CloudGenix avoids some of these common pitfalls experienced with other vendors:
- Using Default Usernames/Passwords – some vendors will use static usernames/passwords that are well-known and/or dictionary-based to provision a device into their fabric.
- Insecure Protocols – Vendors will also default to using HTTP instead of HTTPS to onboard devices. This alone, or in conjunction with using default usernames/passwords, leaves the environment perennially exposed to breaches.
Secured Internet Ports
With CloudGenix, all ports that have an Internet connection/label automatically have a firewall applied, allowing only VPN traffic to connect to these interfaces. With other vendors, this feature must be explicitly configured.
Leveraging a firewall by default for all Internet ports solves for the following challenges:
- Weakness Exposure – If a device is publicly exposed, it can be scanned/examined for any vulnerabilities or weaknesses. Readily available scanners, such as NMAP and Nessus can be used to view open ports/protocols; from there, deprecated crypto libraries, vulnerabilities, and more can be searched for and optionally exploited, if present.
- Login Using Default Username/Passwords (Part 2) – The above scenario, combined with the use of static usernames/passwords, exposes devices to unintended or unsecure configuration changes. In some cases, these changes cannot be not easily altered or discovered. This can allow remote attackers to connect directly and repeatedly to a branch device.
One of the biggest weaknesses of any VPN implementation is the keys used for encryption. If encryption keys are weak and/or rotated infrequently, it presents an opportunity for malicious actors to decrypt the traffic and intercept/inject themselves into the traffic stream.
CloudGenix takes advantage of several technologies and techniques that mitigate or eliminate the issues commonly associated with keys. Some of these strategies include, but are not limited to:
- Unique Keys Per Path – CloudGenix utilizes a unique key pair for each path. This means that, unlike other vendor implementations, deciphering a key pair never exposes all of the links at a given location.
- Key rotation – Some vendors create a session key and use that key for up to a week without rotation — or worse yet, the keys are static. While you can tune or adjust these key lifetimes, our belief at CloudGenix is that you, the customer, should never need to do so. Our keys rotate every hour, without any need to communicate with the controller.
- Session Key knowledge – Some vendors have an architecture whereby the controller/ central entity knows what the sessions key(s) are for each VPN in the network. In the CloudGenix architecture the controller has no knowledge of the session keys, only the two devices that have formed the VPN have knowledge of the session keys.
Management and Analytics Protection
The heart of any SDWAN system is its management console and associated analytics. Our approach to protecting this environment is the same as with the rest of our ecosystem: hardened security with minimal or zero user intervention.
We take a number of steps to protect the Management and Analytics of our SDWAN:
- Management Protocol Access – CloudGenix defaults to the highest possible encryption algorithm strength for access to the management environment, and leaves lower algorithms disabled.
- Static User Passwords – At the end of the day, we do allow for human access, and humans like to use passwords. To offer additional protection for management access, CloudGenix can layer features on top of this:
- CloudGenix offers and recommends customer use SAML (Security Assertion Markup Language) for dual-factor authentication
- For customers unable to leverage SAML, we can provide controls like password complexity requirements, failed attempt lockouts, IP access restrictions, and much more. Other vendors may simply restrict your access from an IP address or IP address(es)
- Device Communications – Depending on the vendor, there may only be a single encrypted session for sending data back to the controller entity for traffic analytics, control and management, and the like. However, some vendors also choose to send data in plain text, as it is simply “logging.” Worse, all of these events can occur over a single communications channel.At CloudGenix, we believe that the data/logs are just as important as the management of the system, as they can be used to glean information about a customer’s network — providing insights or information that was never meant to be exposed. CloudGenix has several controls in place to reduce or eliminate this risk:
- Multiple discrete channels from a device to the controller, in order to separate logging, control, and other functions across more than a single channel.
- No user or company data is stored or sent to the controller. As such, there is no regulatory governance applied such as GPDR, HIPAA, PCI that might limit operations of an SD-WAN in a cloud environment
While there are many more features and strategies that we at CloudGenix enable to enhance security, the above list provides a sample of what we do to help secure our customers’ SD-WAN environments.
When evaluating an SDWAN vendor, make sure to ask tough questions about how they secure the environment on your behalf. The list of features for which vendors should provide answers as to how they are secured must include (but is not limited to):
- Zero Touch Provisioning
- Default (or hardcoded) Username/Passwords
- Device/Port Security for Public Ports
- Key Management
- Management Communications
Our belief at CloudGenix is that, while ease of implementation and use is obviously critical, it can never come at the expense of security. Customers deserve nothing less than industry-leading best practice, when it comes to securing their SD-WAN environments.