The concept of “security by design” might seem ambiguous, but its impact on our connected devices is undeniable. Recent regulations like the Cyber Resilience Act (CRA) mandate security as a core principle, making it crucial to understand how this translates to everyday practices.
While defining “security by design” can be nuanced, there are clear indicators that a device falls short. One red flag is the presence of access protocols like SSH and RPC with readily available credentials. These protocols, in the wrong hands, can grant external parties complete control over the device, leaving it vulnerable to exploitation.
There are, however, rare exceptions. Devices designed specifically for tasks like load balancing may require RPC functionality. Nevertheless, for most devices, having these services active renders them ineligible for CRA certification and exposes them to significant risks.
For existing devices deployed before CRA, a simple port scan can reveal potential vulnerabilities. Tools like “nmap” can check if ports 22, 111, or 135 (or other ports associated with these protocols) are open. An open port suggests a “time bomb” waiting to happen.
Certain situations, like requiring remote maintenance via SSH, present a challenge. Our recommendation? Keep the SSH port closed by default and empower the customer, not the manufacturer, to activate it upon need. This approach allows for CRA certification while keeping the risk relatively low.
Platforms like i46.io offer solutions that comply with CRA by enabling customer controlled, remote activation of SSH services. This empowers users to maintain security while accessing necessary functionalities when needed.
Understanding security by design is crucial in today’s connected world. By being aware of red flags and implementing customer-centric solutions, we can ensure the safety and security of our devices and, ultimately, ourselves.