Lines Matching +full:level +full:- +full:detect
1 .. _security-overview:
14 documents are created, this document is a top-level overview and entry
32 relevant sub-modules is created, threats are identified, and
43 .. figure:: media/security-process-steps.png
64 noted in RFC-2119, "These terms are frequently used to specify behavior
98 - **Security** **Functionality** with a focus on cryptographic
104 - **Quality Assurance** is driven by using a development process that
107 blocks such as network stacks increases the overall quality level
111 - **Execution Protection** including thread separation, stack and
150 thread execution level, and memory protection constraints are enforced
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
185 "survivability" was coined to cover pro-active security tasks such as
190 they are closed as non-issues (at least another person educated in
191 security processes need to agree on non-issue before closing).
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
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
281 - **Open design** as a design principle incorporates the maxim that
283 widespread use. Instead of relying on secret, custom-tailored
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
303 - **Separation of privilege** is the principle that two conditions or
308 - **Least privilege** describes an access model in which each user,
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
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
373 - **Code Reviews** ensure the functional correctness of the code base
375 check-in. Code reviews shall be performed by at least one
378 developers on a functional level and are to be distinguished from
382 - **Static Code Analysis** tools efficiently detect common coding
387 waive potential false-positives before each release.
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
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
461 - **Adherence to the Secure Development Coding** is mandatory to
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
476 - **Security Issue Management** encompasses the evaluation of potential
482 system level, and for each security related module of the secure branch
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
526 mitigate existing weaknesses. Newly developed sub-modules that are
529 Additionally, their impact on the system level security shall be
588 On a pure software level, this encompasses
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
622 certification scheme and evaluation level, this process needs to be
641 which the vendor could use to certify their Zephyr-enabled
656 The security architecture, for example, considers assets on system level
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
687 certification/assurance level need to be determined.
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