Lines Matching +full:split +full:- +full:security
1 .. _security-overview:
3 Zephyr Security Overview
9 This document outlines the steps of the Zephyr Security Subcommittee towards a
10 defined security process that helps developers build more secure
11 software while addressing security compliance requirements. It presents
12 the key ideas of the security process and outlines which documents need
14 documents are created, this document is a top-level overview and entry
21 mainly focuses on security functionality.
30 2. **Secure Design:** Defines security procedures and implement measures
31 to enforce them. A security architecture of the system and
32 relevant sub-modules is created, threats are identified, and
36 and mitigating security issues.
38 3. **Security Certification:** Defines the certifiable part of the
43 .. figure:: media/security-process-steps.png
45 Figure 1. Security Process Steps
50 This document is a guideline for the development of a security process
51 by the Zephyr Security Subcommittee and the Zephyr Technical Steering
52 Committee. It provides an overview of the Zephyr security process for
53 (security) engineers and architects.
64 noted in RFC-2119, "These terms are frequently used to specify behavior
65 with security implications. The effects on security of not implementing
68 time to elaborate the security implications of not following
73 Security Document Update
83 2. The Zephyr Security Subcommittee will review these changes and provide feedback
88 Current Security Definition
92 within the Zephyr RTOS. Currently, focus is put on functional security
93 and code quality assurance, although additional security features are
96 The three major security measures currently implemented are:
98 - **Security** **Functionality** with a focus on cryptographic
104 - **Quality Assurance** is driven by using a development process that
111 - **Execution Protection** including thread separation, stack and
119 Security Functionality
122 The security functionality in Zephyr hinges mainly on the inclusion of
137 The security architecture is based on a monolithic design where the
146 features to split the system into privileged and unprivileged execution
164 - Verifying correct functionality of the implementation
166 - Increasing the readability and maintainability of the contributed
169 - Ensuring appropriate usage of string and memory functions
171 - Validation of the user input
173 - Reviewing the security relevant code for potential issues
177 the experience of the reviewer. Especially for security relevant code,
185 "survivability" was coined to cover pro-active security tasks such as
186 security issue categorization and management. A problem identified as
187 vulnerability is managed within Github security advisories.
190 they are closed as non-issues (at least another person educated in
191 security processes need to agree on non-issue before closing).
193 A security subcommittee has been formed to develop a security process in
202 - **Memory separation:** Memory will be partitioned into regions and
206 - **Stack protection:** Stack guards would provide mechanisms for
210 - **Thread separation:** Individual threads should only have access to
216 System Level Security (Ecosystem, ...)
219 System level security encompasses a wide variety of categories. Some
222 - Secure/trusted boot
223 - Over the air (OTA) updates
224 - External Communication
225 - Device authentication
226 - Access control of onboard resources
228 - Flash updating
229 - Secure storage
230 - Peripherals
232 - Root of trust
233 - Reduction of attack surface
244 software security. Furthermore, a system architecture document shall be
245 created and kept up-to-date with future development.
250 .. figure:: media/security-zephyr-system-architecture.png
254 A high-level schematic of the Zephyr system architecture is given in
256 Services*) and a user-specific part (*Application Services*). The OS
257 part itself contains low-level, platform specific drivers and the
258 generic implementation of I/O APIs, file systems, kernel-specific
267 basis for the security architecture. Please refer to the
279 security violations and limit their impact:
281 - **Open design** as a design principle incorporates the maxim that
283 widespread use. Instead of relying on secret, custom-tailored
284 security measures, publicly accepted cryptographic algorithms and
287 - **Economy of mechanism** specifies that the underlying design of a
292 - **Complete mediation** requires that each access to every object and
296 - **Fail-safe defaults** defines that access is restricted by default
300 way to provide maximum security. This corresponds to the "Secure
303 - **Separation of privilege** is the principle that two conditions or
305 context of the Zephyr project, this could encompass split keys
308 - **Least privilege** describes an access model in which each user,
311 task. This positive security model aims to minimize the attack
314 - **Least common mechanism** specifies that mechanisms common to more
320 - **Psychological acceptability** requires that security features are
327 - **Complementary Security/Defense in Depth:** do not rely on a single
328 threat mitigation approach. In case of the complementary security
334 - **Less commonly used services off by default**: to reduce the
342 be disabled. The user shall be notified if low-level options and
345 - **Change management:** to guarantee a traceability of changes to the
363 - **Adherence to the Coding Conventions** with respect to coding style,
367 automated scripts prior to check-in.
369 - **Adherence to Deployment Guidelines** is required to ensure
370 consistent releases with a well-documented feature set and a
371 trackable list of security issues.
373 - **Code Reviews** ensure the functional correctness of the code base
375 check-in. Code reviews shall be performed by at least one
379 security reviews as laid out in the `Secure Design`_ section.
382 - **Static Code Analysis** tools efficiently detect common coding
387 waive potential false-positives before each release.
394 main release branch and on the security branch. It shall be
400 - **Complexity Analyses** shall be performed as part of the development
405 - **Automation:** the review process and checks for coding rule
418 - **Device management** encompasses the possibility to update the
419 operating system and/or security related sub-systems of Zephyr
422 - **Lifecycle management:** system stages shall be defined and
424 system state diagram. For security reasons, this shall include
428 - **Release management** describes the process of defining the release
435 - **Rights management and NDAs:** if required by the chosen
438 separate source code repository) and non-disclosure agreements
449 In order to obtain a certifiable system or product, the security process
451 and driven. This process includes the development of security related
452 modules in all of its stages and the management of reported security
459 The software security process includes:
461 - **Adherence to the Secure Development Coding** is mandatory to
462 avoid that individual components breach the system security and
465 investigate the correct implementation of security features such
466 as countermeasures manually in security-critical modules.
468 - **Security Reviews** shall be performed by a security architect in
469 preparation of each security-targeted release and each time a
470 security-related module of the Zephyr project is changed. This
472 implemented security measures, the adherence to the global
473 security strategy and architecture, and the preparation of audits
474 towards a security certification if required.
476 - **Security Issue Management** encompasses the evaluation of potential
478 :ref:`Security Issue Management <reporting>`.
482 system level, and for each security related module of the secure branch
483 of Zephyr, a directly responsible security architect shall be defined to
486 Security Architecture
490 security design on system- and module-level. The high level
493 - The identification of **security and compliance requirements**
495 - **Functional security** such as the use of cryptographic functions
498 - Design of **countermeasures** against known attack vectors
500 - Recording of security relevant **auditable events**
502 - Support for **Trusted Platform Modules (TPM)** and
505 - Mechanisms to allow for **in-the-field** **updates** of devices using
508 - Task scheduler and separation
510 The security architecture development is based on assets derived from
516 security relevant status information.
521 3. **Definition of requirements** regarding security and protection of
524 The security architecture shall be harmonized with the existing system
526 mitigate existing weaknesses. Newly developed sub-modules that are
528 individual documents describing their security architecture.
529 Additionally, their impact on the system level security shall be
532 Security Vulnerability Reporting
535 Please see :ref:`reporting` for information on reporting security
541 The modeling of security threats against the Zephyr RTOS is required for
542 the development of an accurate security architecture and for most
551 model is then considered in the module and system security architecture
572 security reviews, the threat models and the mitigation techniques shall
573 be evaluated by the responsible security architect.
578 that the security is not impaired by regressions.
590 - **Penetration testing** of the RTOS on a particular hardware
594 - **Side channel attacks** (timing invariance, power invariance, etc.)
600 - **Fuzzing tests** shall be performed on both exposed APIs and
606 The findings of these analyses shall be considered in the security issue
613 Security Certification
636 2. Developing a **threat model** and **security architecture** to
640 split model containing a precertified secure branch of Zephyr
641 which the vendor could use to certify their Zephyr-enabled
645 **certification claims** on the security of the assets to be
650 consistent documentation of the security development process,
656 The security architecture, for example, considers assets on system level
662 For the security certification as such, the following options can be
684 In all three cases, the certification scheme (e.g., FIPS 140-2 [NIST02]_
686 (main-stream Zephyr, security branch, or certain modules), and the
693 - **Appropriate physical security** of the hardware platform and its
696 - **Sufficient protection of storage and timing channels** on
700 - Only **trusted/assured applications** running on the device
702 - The device and its software stack is configured and operated by
706 These assumptions shall be part of the security claim and evaluation