Lines Matching +full:secure +full:- +full:only
3 Secure Coding
6 Traditionally, microcontroller-based systems have not placed much
33 We begin with an overview of secure design as it relates to
35 a section on `Secure development knowledge`_, which
38 documents, and full details of how to write secure software are beyond
46 documentation about how security-sensitive issues are handled by the
52 Secure Coding
55 Designing an open software system such as Zephyr to be secure requires
60 - **Open design** as a design guideline incorporates the maxim that
62 widespread use. Instead of relying on secret, custom-tailored
66 - **Economy of mechanism** specifies that the underlying design of a
71 - **Complete mediation** requires that each access to every object and
75 - **Fail-safe defaults** defines that access is restricted by default
76 and permitted only in specific conditions defined by the system
79 to provide maximum security. This corresponds to the "Secure by
82 - **Separation of privilege** is the principle that two conditions or
86 - **Least privilege** describes an access model in which each user,
92 - **Least common mechanism** specifies that mechanisms common to more
98 - **Psychological acceptability** requires that security features are
103 specific to the development of a secure RTOS:
105 - **Complementary Security/Defense in Depth**: do not rely on a single
112 - **Less commonly used services off by default**: to reduce the
114 shall not be enabled by default if they are only rarely used (a
120 shall be notified if low-level options and APIs are enabled but not
123 - **Change management**: to guarantee a traceability of changes to the
131 Secure development knowledge
134 Secure designer
138 how to design secure software.
143 - economy of mechanism (keep the design as simple and small as
146 - fail-safe defaults (access decisions shall deny by default, and
147 projects' installation shall be secure by default)
149 - complete mediation (every access that might be limited must be
150 checked for authority and be non-bypassable)
156 - open design (security mechanisms should not depend on attacker
160 - separation of privilege (ideally, access to important objects should
162 system won't enable complete access. For example, multi-factor
164 token, is stronger than single-factor authentication)
166 - least privilege (processes should operate with the least privilege
169 - least common mechanism (the design should minimize the mechanisms
173 - psychological acceptability (the human interface must be designed
174 for ease of use - designing for "least astonishment" can help)
176 - limited attack surface (the set of the
179 - input validation with allowlists (inputs should typically be checked
181 validation should use allowlists (which only accept known-good
182 values), not blocklists (which attempt to list known-bad values)).
197 software. If there is only one developer, that individual is the
205 injection, OS injection, classic buffer overflow, cross-site
211 mitigate linear stack/heap buffer overflows, non-linear out of bound writes,
212 integer overflows, and other integer issues. The follow-on class, `OST2_1002`_,
213 covers uninitialized data access, race conditions, use-after-free, type confusion,
221 .. _OWASP Top 10: https://owasp.org/www-project-top-ten/
245 secure designer to also review the code. Any of these individuals
260 field shall result in the issue only being visible to the Zephyr Security
265 This embargo, or limited visibility, shall only be for a fixed
266 duration, with a default being a project-decided value. However,
288 .. _attack: http://www.theverge.com/2016/10/21/13362354/dyn-dns-ddos-attack-cause-outage-status-exp…