Lines Matching full:security
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
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
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.
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
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
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.
191 security processes need to agree on non-issue before closing).
193 A security subcommittee has been formed to develop a security process in
216 System Level Security (Ecosystem, ...)
219 System level security encompasses a wide variety of categories. Some
244 software security. Furthermore, a system architecture document shall be
250 .. figure:: media/security-zephyr-system-architecture.png
267 basis for the security architecture. Please refer to the
279 security violations and limit their impact:
284 security measures, publicly accepted cryptographic algorithms and
300 way to provide maximum security. This corresponds to the "Secure
311 task. This positive security model aims to minimize the attack
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
371 trackable list of security issues.
379 security reviews as laid out in the `Secure Design`_ section.
394 main release branch and on the security branch. It shall be
419 operating system and/or security related sub-systems of Zephyr
424 system state diagram. For security reasons, this shall include
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:
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
500 - Recording of security relevant **auditable events**
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
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.
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
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
686 (main-stream Zephyr, security branch, or certain modules), and the
693 - **Appropriate physical security** of the hardware platform and its
706 These assumptions shall be part of the security claim and evaluation