Device Security: You vs. Future Security Vulnerabilities

If testing and protecting your device from known issues, is equivalent to closing a treasure vault’s door, by that analogy, keeping the door shut involves product testing for unknown issues. Similarly, making the door harder to open, then becomes the act of proactively updating your device to prevent future issues.

In our last blog, we talked about “closing the door” i.e., protecting the device from known vulnerabilities. Now, we explore the next two actions.

Product Testing for Unknown Security Issues 

Many of the challenges in securing devices is protecting your device from vulnerabilities that were unknown when the product was released.

Ever heard of the old adage, “Think like the enemy”? ―You can try to duplicate the techniques used by hackers before your product is released. There are two major ways to do this:

Penetration testing

When we typically visualize the exploitation/compromission of a device, it evokes images of “bad guys” (criminals, governmental actors, industrial espionage, etc.) with nefarious intentions. However, the techniques used by these “black hat hackers”, are not rocket science; they are well-known in the community.

These techniques and the ingenuity of software developers are how these exploits are found. An organization can do the same on their own devices; having engineers or “white hat hacker” consultants attempt to exploit your devices before they are released to the market.

This process is referred to as penetration testing, where you allow a cybersecurity attack against your devices. However, instead of the results being used against you, the results are reported to you while you can do something to prevent those exploits in the field.

Fuzz testing

Another type of analysis that hackers perform is to probe a device with a large amount of valid and invalid Ethernet packets that they can control and monitor. Many of these sequences will be more random such as malformed or semi-malformed packets, just to see what happens.

This kind of testing is known as fuzz testing, and while not as effective as penetration testing, fuzz testing is much easier to implement as part of the standard testing of your product. Additionally, there are several products on the market that performed fuzz testing and can be integrated into an automated testing framework.

Generally, penetration testing can only be performed once or twice during a product’s development and testing, while fuzz testing can be performed periodically (for example, once a week), and as part of any formal testing regimen.

Product Maintenance in a Constantly Changing Security Landscape 

As mentioned before, you must consider product maintenance during product development, so that the product may be updated safely and securely when the inevitable issues arise.

These issues can be product upgrades, resolutions to product functionality issues, or resolutions to newly found exploits. You should establish a regular update frequency for your released products. Having a regular update frequency allows your customers to schedule predictable and minimal downtimes. Since many devices are mission-critical for your customers, striking a balance between update frequency and downtime is critical

What to ask Your Operating System Provider

Using an operating system (OS) provider such as Siemens Embedded can be a great benefit to your product development. The OS provider focuses on the OS as a product unto itself. They develop, test, and release the product to a degree that is beyond what your teams can do themselves. This gives you the best chance at staying on top of known vulnerabilities, being prepared to handle unknown vulnerabilities, and having ways to prevent future vulnerabilities.

Considering the importance and criticality of choosing and maintaining the best OS for you, you should ask your OS provide, some key questions:

• How do they test the OS and related products and packages, including board support packages, drivers, and other software necessary to deploy the OS on your target?
  
• Can they provide services and support to you that will accelerate your product development, including the security of your device?

• How often do they update their products, and what kinds of improvements should you expect to see in those updates?

The OS provider should be strongly focused on security vulnerabilities, including CVEs. Your OS vendor should be able to provide greater service around these issues, which is especially important if your device has to undergo regulatory approval (such as in medical or automotive devices).

Customers are aware that there is no device that is completely free of bugs. What they want to know is how you are minimizing defects and their impact, and how ready are you when something inevitably goes wrong. 

The methods discussed above, will not prevent all potential future security issues, but they will put you in a good position to quickly resolve those issues when they arise.

Download these whitepapers on device security.

Medical device security: achieving regulatory approval

Minimizing Device Security Vulnerabilities using Embedded Linux

---