This page describes the CPE security hardening baseline that RansNet applies to Customer Premises Equipment (CPE) such as SD-WAN gateways (CMG, HSA, UA) to comply with industry best practices, including CIS Benchmarks where applicable, during device onboarding, provisioning, and firmware updates to ensure devices are securely configured before deployment.
CIS Benchmarks are security hardening standards developed by the Center for Internet Security (CIS). They outline detailed, widely-accepted configuration recommendations for systems ranging from operating systems (e.g., Linux, Windows) to network devices and applications.
For embedded CPE devices, not all CIS controls apply directly. RansNet CPE device OS/image are prebuilt with functionally equivalent controls where native CIS rules cannot be applied due to platform constraints. These benchmarks serve as a baseline for secure configuration that auditors, integrators, and service providers often reference.
RansNet CPE hardening aligns with the following CIS Benchmarks:
Primary: CIS Benchmark for Linux (Level 1 - Enterprise) - Sections applicable to embedded systems
Supplementary: CIS Benchmark for Network Devices (v2.0)
Framework Reference: CIS Critical Security Controls v8
This hardening baseline aims to:
Reduce the device attack surface
Enforce secure defaults
Protect against common network attacks (e.g., SYN floods, brute force, unauthorized access)
Improve resilience against denial of service threats
Ensure consistent security posture across deployed devices
Below controls highlights some critical controls needed as part of CPE deployments.
Some controls are default (built as part of the OS, already in compliance to CIS and can't be changed, marked as "OS default"); The rest will need actions, as part of the hardening process.
1. Operating System and Services
Default credentials must be changed before onboarding.
<change default password at first login>
Unused services (e.g., telnet, FTP) are disabled.
<OS default>
Privileged access (e.g., root/enable) is restricted and, where possible, secured using management controls.
<Ensure login and enable passwords are different and comply to corporate security policy)
Firmware is kept up-to-date with the latest patches and fixes.
<Upgrade to latest STABLE after onboarding>
2. Management and Access Controls
Management access (SSH/HTTPS) is enabled only over secure channels.
<Configure VRF for management interface and configure firewall-input rule to permit authorized source IPs only>
Telnet and unencrypted management interfaces are disabled by default.
<OS default>
Idle session timeouts are configured.
<OS default>
Where practical, SSH key-based authentication is enforced.
<Recommended to disable SSH, or configure firewall-input rules to allow authorized source IP>
3. Network and Firewall Hardening
Stateful firewall is enabled by default.
<OS default>
Default deny rules apply to untrusted interfaces.
<OS default>
Management and control ports are restricted by ACLs where applicable.
<Configure VRF for management interface and configure firewall-input rule to permit authorized source IPs only>
Address translation and NAT used responsibly according to policy.
<Review firewall rules. strictly no "permit all" type of rules.>
Rate limiting for TCP SYN, ICMP, and other known flood vectors is applied at the network layer to mitigate DoS attacks.
<Configure rate limiting for management (SSH/HTTPS) service, if these are allowed.>
4. Cryptography and TLS
Only modern TLS versions (TLS 1.2 and TLS 1.3) are enabled.
<OS default>
Weak protocols (SSL, TLS 1.0, TLS 1.1) are disabled.
<OS default>
Cipher suites adhere to strong cryptographic practices (e.g., forward secrecy, strong AEAD algorithms).
<OS default>
Certificate validation and management follows industry best practices.
<Review company SOP and use valid SSl certificates and rotate yearly.>
5. Logging and Monitoring
System and security logging is enabled.
<Enable logging for firewall rules and export out logs to syslog collector>
Events such as authentication attempts, firewall drops, and configuration changes are logged.
<Deploy syslog collect to receive logs to all devices>
NTP time synchronization is configured for consistent timestamps.
<Use customer internal NTP server if available>
Logs are retained according to operational procedures.
<Configure log archival for long-term retention>
To demonstrate compliance with this baseline during audits:
Configuration screenshots or exports of firewall rules can be provided.
Logs showing management ACLs, rate limiting, and disabled services can be included.
A signed device onboarding checklist showing that hardening controls are verified can be attached to audit artifacts.
This approach aligns with CIS Benchmarks where applicable and documents deviations where the embedded operating system or device role requires different implementations.
Onboarding Hardening Checklist
You may use below simple checklist as part of your UAT/implemtation report
☐ Default passwords changed
☐ Unused services disabled
☐ Firewall enabled and default deny in place
☐ Management access restricted (SSH/HTTPS)
☐ Rate limiting enabled for SYN, ICMP, UDP
☐ TLS configuration restricted to TLS 1.2/1.3 with strong ciphers
☐ Logging enabled and verified
☐ Configuration export archived
This hardening baseline is reviewed at least annually or when significant security requirements change. Any deviations are documented and approved through the RansNet security governance process.