Curriculum for

Certified Professional for
Software Architecture (CPSA)^®
Advanced Level:
Module
EMBEDDEDSEC

Embedded Security for Architects

Participants know a definition of security and understand it as a quality of the system. Participants understand the relationship and trade-offs to other quality attributes.

Definitions can be found for example in ISO/IEC 25010, ISO/SAE 21434 and IEC 62443.

Participants know the security properties of the universal triad: confidentiality, integrity and availability. In addition they know additional common properties such as authentication, authorization and non-repudiation.

Participants understand, that security must be considered in the whole product lifecycle and not just for the development phase. Participants understand that maintaining security requires participation and consideration of all stakeholders. Participants know the typical lifecycle phases (conception, development, production, operation and maintenance, and decommission). Participants know at least one example of a security product lifecycle.

Examples of security product lifecycles are presented ISO/SAE 21434, the Microsoft Security Development Lifecycle and NIST’s Secure Software Development Framework.

Participants understand the difference between regulations, standards and guidelines. Participants know examples of regulations, standards and guidelines regarding security.

Example of security regulations, standards and guidelines are UN R 155, UN R 156, ISO/SAE 21434, FDA Guidelines, NIST Standards such as SP800, IEC 62443, IEC 80001-5-1, IEC 60601-4-5, ISO 270xx and ETSI EN 303 645.

Participants understand the security purpose of the system context. Participants are able to create a system context view, building on their Foundation Level knowledge. The system context provides necessary information for the security analysis of the system:

Participants understand what assets are and know typical examples. Participants are able to identify assets for a given system. Participants are able to identify damage scenarios an attack can cause these assets.

Examples of assets in embedded systems are personally identifiable information, user’s health and safety, intellectual property, hardware components, cryptographic material and communication channels.

Participants know approaches to threat modeling (attacker-, asset-, system-centric) and understand their advantages and disadvantages. Participants understand the role threat modeling plays in the product lifecycle phases and that the model changes over time. Participants understand that threat modeling is an interdisciplinary tasks, that benefits from diverse inputs.

Participants know approaches to identifying threats (e.g., Misuse Case Diagram, Data Flow Diagram, STRIDE). Participants understand how architectural views can be employed for threat modeling. Participants know typical methods to refine threats with attack paths (e.g., Attack Tress, Vulnerability Analysis, Kill-Chains). Participants are able to identify and analyze threats for a given system.

Participants understand the goal of assessing the risk of threats and the associated damage scenarios. Participants know approaches to classifying and rate attack risks.

Examples for common rating systems are CVSS, ISO/SAE 21434 and MITRE’s Medical CVSS rubric.

Participants understand the goals of security verification. Participants know classifications of security Verification methods:

Participants understand the advantages and disadvantages of static and dynamic methods.

Participants know static analysis techniques such as

Participants know dynamic testing techniques such as

Participants understand the goal of penetration testing. Participants understand the relationship of penetration testing to other verification methods. Participants know the steps of a penetration test:

Participants know the goals of cryptography (Protection of authenticity, confidentiality and integrity). Participants know how a basic cryptographic function works.

Participants understand what symmetric cryptography is. Participants know use cases, advantages and disadvantages of symmetric cryptography. Participants know examples of recommended symmetric algorithms (e.g. from NIST or BSI).

Participants understand what asymmetric cryptography is. Participants know use cases, advantages and disadvantages of asymmetric cryptography. Participants know examples of recommended asymmetric algorithms (e.g. from NIST or BSI) and are aware of the need to future-proof applications for post-quantum attacks.

Participants understand what a hash function does. Participants understand quality goals of hash functions (preimage resistance, second-preimage resistance, collision resistance, avalanche effect and uniqueness of output). Participants know use cases of hashing. Participants know examples of recommended hashing algorithms (e.g. from NIST or BSI).

Participants understand the use of key derivation functions. Participants understand the difference in qualities compared to hashing functions. Participants know examples of recommended key derivation functions and their uses (e.g. from NIST or BSI)

Participants understand why cryptographically-secure random values are an important cornerstone of cryptography. Participants know how random values can be generated through random number generators (RNGs) and pseudo-random random number generators (PRNGs). Participants are aware of common pitfalls, when generating random values.

Participants know the levels of capabilities (script kiddy, programmer, security expert, state actor/competitor, etc.) and motivations (fun, research, monetary gain) attackers exhibit. They should understand the issues with attacker-based risk approaches.

Participants understand the difference between weaknesses and vulnerabilities. They understand the concept of an attack surface and how it relates to weaknesses and vulnerabilities.

Participants know sources from which information about attacks, vulnerabilities and weaknesses can be gathered (e.g., CVE and CWE database, OWASP, SANS Institute, CISA, BSI, or UN R 155 for automotive).

Participants understand typical weaknesses, attack patterns and their effects. Examples for these are overflows, injections, privilege escalations, denial of service, attacker-in-the-middle, reverse engineering, social engineering. Further examples can be found in the OWASP (IoT) Top 10 and aforementioned security information sources.

Participants understand that attacks on embedded systems are not limited to software-based attacks, but can also be conducted via the system’s hardware. Participants know that hardware attacks can be invasive, therefore damaging the device under attack, or non-invasive. Participants know hardware-based attacks such as side channel attacks, voltage glitching, or microprobing.

Participants understand security as a system quality and its relation to other quality requirements. Participants understand security as a quality in the context of ISO 25010 and the relation of these qualities to the threat modeling analysis technique STRIDE. Participants understand that embedded security is a cross-cutting concern, that needs to be addressed at the system, hardware and software level and can not be solved only in software.

Participants understand, that the physical access users can gain to the devices pose an uncircumventable risk, therefore it should be considered that the compromise of single device should not compromise all products (e.g., when the same symmetric key is used in all devices).

Participants understand that embedded systems can influence the physical world and pose additional safety risks that need to be addressed.

Participants understand that good software engineering practices help designing a more secure system. They are able to explain why a modular design supports achieving security goals.

In addition, participants know design principles to building secure systems and how they are reflected in embedded systems, examples include:

Participants understand that resource constraints limit the solution space for embedded systems. Examples of such limitations are:

Participants understand the need for software updates and the challenges deploying updates to embedded devices pose. Participants know the security trade-off of updatable devices, as this mechanism increase the devices attack surface. Participants know possible solutions to securely deploy updates to embedded devices (e.g., signed and encrypted firmware packages, secure version numbers)

Participants understand how a well engineered implementation supports the security goals. Participants know standards and guidelines to reduce the likelihood of introducing defects during the implementation such as MISRA, CERT Coding Guidelines or OWASP’s Secure Coding Practices.

Participants know methods, patterns and technologies to ensure authentication of entities and manage authorization for actions taken on the system.

Authentication example patterns are

Authorization example patterns are

Participants understand that users in embedded systems might be other systems and system-to-system authentication and authorization needs to be addressed, compared to user-to-system authentication. Participants understand that user interaction with the device might be limited, when selecting authentication mechanisms.

Participants know methods, patterns and technologies to ensure the system’s integrity and protect the system against tampering.

Examples to ensure software integrity are

Examples to ensure integrity of operations are

Participants understand the necessity of ensuring confidentiality, integrity and availability of communication. Participants know mechanisms to harden communication against attacks such as

Participants understand that embedded buses are limited in bandwidth and message size, therefore security mechanisms for protecting communication over such buses might have lower security guarantees compared to TLS or other typical communication protection.

Participants understand what role the underlying hardware plays in achieving security goals. Participants know how isolation concept can be realized with hardware support, what a Hardware Security Module or a Trusted Platform Module is. Participants know examples of hardware security mechanisms such as Physical Unclonable Functions (PUF) or Fuses. Participants know that hardware interfaces might need to be disabled for a production deployment, e.g., serial and debug interfaces Participants know examples for anti-temper protection such as temper sensors, coatings and potting, physical access protection.

Participants understand the concept of secure enclaves and now examples of implementations, such as the ARM’s TrustZone, the Confidential Compute Architecture, or the Secure Hardware Extension (SHE).