The ever-increasing connectedness of electronic systems provides a whole new world of opportunity. But with that opportunity comes a brand-new challenge; keeping your functional system safe and secure, especially when there is a need for certification.
Free seminars in Munich, 6 March 2018; Frankfurt, 7 March 2018; and Eindhoven, 8 March 2018; will highlight several issues to consider when designing a functionally safe secure system and will detail how, alongside features such as domain separation and rootkit protection, the security features of the application code itself provide an essential slice in a “Swiss Cheese” defence of a connected system. A demonstration of how automated tools can streamline the development of securely coded applications is included.
Sometimes, the need for security is obvious – perhaps in the banking sector, or when classified government information is involved. On other occasions, the requirement is more subtle. For example, it is a vital consideration for connected electronic systems required to meet industrial (e.g. IEC 61508) or automotive (e.g. ISO 26262) functional safety standards because connected systems cannot be safe if they are vulnerable to cyberattack.
These cyberattacks take a host of different forms, and there are many perspectives to consider. For example, rootkits allow viruses and malware to “hide in plain sight” by disguising as necessary files that antivirus software will overlook, and then remain undetected while they steal information for an extended period.
Then there are cross-domain attacks, where aggressors access critical domains via their more vulnerable, less critical counterparts. The securing of separate domains is a well-publicized factor in adhering to the principles of either the Industrial Internet Reference Architecture (IIRA) or the Reference Architectural Model for Industrie 4.0 (RAMI 4.0), and increasingly important in the automotive sector. In both cases, the application of MILS “Least Privilege” principles can be of fundamental assistance to minimise the size of attack surfaces.
The application software provides another arrow in the security quiver. If that is not written with security in mind, then it is likely to include vulnerabilities meaning that once a domain is accessed, aggressors have a means to access sensitive data or to modify system functionality. This need has replaced the traditional reactive testing approach with a proven Proactive testing methodology during the development lifecycle to enhance security assurance.
Senior executives, technical managers, system architects, product managers, test engineers or anyone wanting a better understanding of the development of highly secure embedded systems with reduced certification risk and time-to-market should attend.