Exploring Security by Design | Automation.com

Exploring Security by Design

Exploring Security by Design

By Siegfried Müller, Founder and Owner, MB Connect Line 

With their ambitions to digitalization, enterprises develop new products and services daily. The new digital sector provides an enormous potential for new solutions in various industries. It‘s a simple task to purchase low-priced hardware and to merge it with freely available open source applications. Some Linux, Raspberry PI and MQTT are patched together –and another IoT product for internal deployment or even distribution is ready. However, what about IT security?

It‘s easy to imagine that many of these new products and devices are directly connected to the internet, or even establish a bridge from the internet to the company‘s internal network. Furthermore it‘s well known that the connection points of public networks are sensitive. They should only be used by trustworthy devices. But is this trust appropriate for devices only built according to functionality –without using any security guidelines or a security framework? A comparison with functional safety is necessary. Nowadays it‘s difficult to imagine that a new appliance will be developed without a safety risk analysis, or by using safety elements without corresponding certifications. In fact, standards and norms regulate how security components have to be designed and deployed. Within information technology, such regulations don‘t exist yet. With Security by Design comparable methods are known, but still need to be applied.

 

Pentest as universal remedy?

Penetration tests are a method for partial reviews of security levels. They are used for targeted system attacks, to discover security breaches. There are manual and automatic tests, mostly utilized in combination. This may be a good effort to determine the security level. It often turns out that there is not just one breach to fix, but a multitude. Now starting with a patchwork it will always be a compromise. Without anchoring information security in the foundation of the device, like with Security by Design, weak points on the surface can hardly be fixed. That‘s why pentests should be carried out periodically –by the manufacturer and the operator of the system. Such tests can be carried out by service providers or a customized piece of software.

 

Security from the Beginning

By definition Security by Design means “Security from the beginning“. There are different interpretations for this statement. It is often said that it is all about secure software design, which is a matter of reading. In my opinion, secure software also requires certain security hardware elements. Basically, the concept is about taking information security into account during the design process of a product. Many manufacturers in the safety sector apply this well known concept since a long time. I even would like to say that the procedure, based on the Machinery Directive, is also known to most machine builders.

At the beginning there is a risk analysis, a process that is familiar to most users in the automation environment. They live this with every newly designed installation. Considering how the machine should work and how to secure this. First, you determine the purpose and the functions of the product.

Security by Design focuses on security aspects throughout the entire development process.

 

Security by Design by using an industrial router as example

An industrial router which is an interface between the information technology of the office and the production, as example. Of course, as definition alone, it is not enough. In our case, we exactly specified which services and applications, e.g. a web server and VPN, should be available on the router. The risk assessment begins at the interfaces to the outside. These include hardware and software interfaces, such as Ethernet and USB, as well as the user interface and the web server. Each of these interfaces will be considered independently and based on the cyber security standards ISA/IEC-62443 which define minimum requirements for safety. The next step is to look at the motivation or goal of potential attackers - from low-level hackers to government mandated hackers with a lot of budget. Depending on the targeted protection level, the expenditure for security increases. If this part is successfully completed, the framework of the requirements for the router is fixed. With Secure Boot, Secure Element and Secure Firmware, the security concept of the router consists of three components.

 

Secure Boot

The first requirement is to create a secure boot concept. The point here is to make sure, that only software certified by the manufacturer can be started by the router. This was solved with the so-called Trusted Root Chain principle. The trust anchor is the basis, which is represented in a boot ROM (Ready Only Memory). It can be written only once with our certificate and boot loader during production in our company. Only application software which identifies itself via a corresponding certificate can be started. Even with full system access to the router, an attacker can never change the certificate or the boot loader to start manipulated firmware. In the second step the boot loader then checks the firmware in the FLASH memory against the certificate and can thus determine whether it was really signed by MB Connect Line. If this is correct, the operating system starts, otherwise the system stops. Manipulations during attack scenarios in operation as described are never permanent. With every reboot of the router the original firmware will be started. It is an essential point of the concept to prevent that manipulated firmware can be pushed to the router. Due to that it is impossible that an attacker takes over the system permanently.

System start with sustained safety chain from the first stage (X-Loader) to the applications.

 

Secure Element

After the system has been started successfully and safely, it also needs some read / write memory. Somewhere the user-specific settings, such as passwords and VPN certificates, have to be stored. For this purpose, a corresponding encrypted area is assigned on the FLASH. The principle may be familiar to the user of the office sector when he has to enter a password already in the BIOS, while starting the PC. Here the password is used to decrypt the hard disk drive. If someone finds or steals such a PC he will not be able to access the hard drive data. This is similar to the router. If someone gets access to the routers flash memory he still can not read any data.

It would be impractical to enter a password every time you boot the router. A so-called Secure Element helps here. This is a separate hardware component (IC) which stores all passwords, keys and certificates. During checks it only answers with "yes" or "no". That means, a request is made with a hashed password and the device responds whether it is correct. Only in this case the user storage is released with a key of the secure element.

Thanks to Security-Chip, the user data are protected against spying and manipulation.

 

Secure Firmware

The third element is the secure firmware. Well, how can firmware be secure? At this point it should be mentioned: There is no hundred percent security, but everything should be done for safeguarding. First, it is important to provide the developer with the essential knowledge about secure software development. This process does not happen overnight. It requires many workshops and educations. As a manufacturer of security components and solutions, we deal with this topic for quite a number of years now. We ongoing keep rolling that out with our developers and employees. One of our software developers in the embedded area is also certified accordingly. This personal certification is called T.P.S.S.E and is a process for secure software development with re-certification every three years. This already establishes the foundation for secure development. Based on this knowledge it can first be determined in a classical selection process which applications need to be integrated into the firmware. Specifically, it is about the so-called userland of the embedded Linux environment. In the standard distribution of Embedded Linux, mostly supplied with the hardware, many programs are implemented, of which, depending on the application, sometimes only 20% are used. The remaining 80% are of no use, but represent an additional potential gateway for attacks. Our userland contains only what is actually needed. The next step is to examine the specific implementation of the applications. For example, how the authentication to the web server works, or how the web pages will be created. Of course this is very extensive and every application should be examined in detail. Also the configuration of these applications should be checked.

Especially the creation of an application should always follow the motto “Security by Default”, which means the security features should be turned on by default. For example, on web interfaces HTTPS should be enabled instead of HTTP. Likewise, no default passwords should be used. A better way is to provide each device with a randomly generated password.

 

Patch Management

The last element is the so-called patch management. It ensures that emerging security vulnerabilities are quickly detected, closed and the appropriate patch is distributed. In this case open source software has the advantage that it is used by many people and regularly will be maintained by the community. The more users, the faster vulnerabilities are detected. We decided to use the most up-to-date Linux kernel and deliberately returned our adjustments to the so-called mainline kernel. The ideal would be to set up a daily build which means that every day applications are checked for changes in the community. If there is a change, it is immediately integrated into a new firmware. This daily build is automated and works almost overnight. Then, automatic tests with the firmware are performed. At the end the firmware will be released manually and not automatically. The final decision is done by a human. It is important that this whole process, down to the point of deployment, will be bindingly stipulated and lived.

 

Conclusion

Developers are primarily experts in their respective industries and in their field of application. Since then, they have mostly not considered the issue of security in their development process at all or only marginally. This is not an accusation but an insight. However, this inevitably creates security vulnerabilities in the software or in the products. Hackers try again and again to gain access to the systems through these security gaps. This article also clarified that the automation industry already has a lot of experience in dealing with policies and their application - for example at safety, where the implementation is based on a preceding analysis. That's something positive. The planned norms and standards, such as IEC62443, have international significance and increasing impact on future devices and solutions. Nevertheless, security still is not a product, but a process that must be lived.

About the Author

Siegfried Müller is the Founder and Owner of MB Connect Line GmbH. He is also a member in the federal association for  IT Security and a German delegate to the ECSO (European Cyber Security Organisation)

Did you Enjoy this Article?

Check out our free e-newsletters
to read more great articles.

Subscribe Now

MORE WHITE PAPERS NEWS

VIEW ALL

RELATED