Lines Matching +full:scan +full:- +full:limit
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
109 Coverity Scan.
111 - **Execution Protection** including thread separation, stack and
166 - Verifying correct functionality of the implementation
168 - Increasing the readability and maintainability of the contributed
171 - Ensuring appropriate usage of string and memory functions
173 - Validation of the user input
175 - Reviewing the security relevant code for potential issues
184 using the open source Coverity Scan tool. Coverity Scan now includes
188 "survivability" was coined to cover pro-active security tasks such as
194 they are closed as non-issues (at least another person educated in
195 security processes need to agree on non-issue before closing).
206 - **Memory separation:** Memory will be partitioned into regions and
210 - **Stack protection:** Stack guards would provide mechanisms for
214 - **Thread separation:** Individual threads should only have access to
226 - Secure/trusted boot
227 - Over the air (OTA) updates
228 - External Communication
229 - Device authentication
230 - Access control of onboard resources
232 - Flash updating
233 - Secure storage
234 - Peripherals
236 - Root of trust
237 - Reduction of attack surface
249 created and kept up-to-date with future development.
254 .. figure:: media/security-zephyr-system-architecture.png
258 A high-level schematic of the Zephyr system architecture is given in
260 Services*) and a user-specific part (*Application Services*). The OS
261 part itself contains low-level, platform specific drivers and the
262 generic implementation of I/O APIs, file systems, kernel-specific
283 security violations and limit their impact:
285 - **Open design** as a design principle incorporates the maxim that
287 widespread use. Instead of relying on secret, custom-tailored
291 - **Economy of mechanism** specifies that the underlying design of a
296 - **Complete mediation** requires that each access to every object and
300 - **Fail-safe defaults** defines that access is restricted by default
307 - **Separation of privilege** is the principle that two conditions or
312 - **Least privilege** describes an access model in which each user,
318 - **Least common mechanism** specifies that mechanisms common to more
324 - **Psychological acceptability** requires that security features are
331 - **Complementary Security/Defense in Depth:** do not rely on a single
338 - **Less commonly used services off by default**: to reduce the
346 be disabled. The user shall be notified if low-level options and
349 - **Change management:** to guarantee a traceability of changes to the
367 - **Adherence to the Coding Conventions** with respect to coding style,
371 automated scripts prior to check-in.
373 - **Adherence to Deployment Guidelines** is required to ensure
374 consistent releases with a well-documented feature set and a
377 - **Code Reviews** ensure the functional correctness of the code base
379 check-in. Code reviews shall be performed by at least one
386 - **Static Code Analysis** tools efficiently detect common coding
391 waive potential false-positives before each release.
404 - **Complexity Analyses** shall be performed as part of the development
409 - **Automation:** the review process and checks for coding rule
422 - **Device management** encompasses the possibility to update the
423 operating system and/or security related sub-systems of Zephyr
426 - **Lifecycle management:** system stages shall be defined and
432 - **Release management** describes the process of defining the release
439 - **Rights management and NDAs:** if required by the chosen
442 separate source code repository) and non-disclosure agreements
465 - **Adherence to the Secure Development Coding** is mandatory to
470 as countermeasures manually in security-critical modules.
472 - **Security Reviews** shall be performed by a security architect in
473 preparation of each security-targeted release and each time a
474 security-related module of the Zephyr project is changed. This
480 - **Security Issue Management** encompasses the evaluation of potential
494 security design on system- and module-level. The high level
497 - The identification of **security and compliance requirements**
499 - **Functional security** such as the use of cryptographic functions
502 - Design of **countermeasures** against known attack vectors
504 - Recording of security relevant **auditable events**
506 - Support for **Trusted Platform Modules (TPM)** and
509 - Mechanisms to allow for **in-the-field** **updates** of devices using
512 - Task scheduler and separation
530 mitigate existing weaknesses. Newly developed sub-modules that are
557 limit the impact of exploits.
594 - **Penetration testing** of the RTOS on a particular hardware
598 - **Side channel attacks** (timing invariance, power invariance, etc.)
604 - **Fuzzing tests** shall be performed on both exposed APIs and
645 which the vendor could use to certify their Zephyr-enabled
688 In all three cases, the certification scheme (e.g., FIPS 140-2 [NIST02]_
690 (main-stream Zephyr, security branch, or certain modules), and the
697 - **Appropriate physical security** of the hardware platform and its
700 - **Sufficient protection of storage and timing channels** on
704 - Only **trusted/assured applications** running on the device
706 - The device and its software stack is configured and operated by