75 / 84
75
EMBEDDED
MAGGIO
SAFETY&SECURITY |
SOFTWARE
Ci sono differenze notevoli tra gli standard CERT
')H#+ @
À
À
sul medesimo codebase. Strumenti come quel-
*#F+
> À
attuare tale strategia. Tali strumenti eseguono
approfondite analisi del codice software per pre-
venire, rilevare ed eliminare i difetti e applicare
À
-
re la conformità agli standard. Portano con sé il
À
-
tà del software e quindi della riduzione dei costi
complessivi di sviluppo.
Considerazioni conclusive
Progettare un’applicazione safety-critical otti-
G
-
sere impegnativo.
Sicurezza e protezione richiedono un insieme di
strategie, processi, strumenti e competenze che
possono non sovrapporsi del tutto o, addirittura,
Á % H
-
À
À
a problemi e a vulnerabilità sia della sicurezza
sia della protezione, come parte di un approccio
olistico.
CERT C
Analisi
Restrizioni (gruppo di lavoro)
Aperto e pubblico (web)
Struttura
143 Rules / 16 Directives
Le Roles sono linee guida per le quali è stata fornita una descrizione
completa dei requisiti.
Le Directives sono linee guida per le quali non è possibile fornire
la completa descrizione necesaria per eseguire una verifica della
conformità.
98 Rules / 178 Recommendations
Le Rules sono definite in base a tre criteri:
1. La violazione delle linee guida è probabile diventi un difetto della
sicurezza
2. Non si basano su annotazioni al codice sorgente o su ipotesi di
intenti del programmatore
3. La conformità alle linee guida può essere determinata mediante
analisi automatica, metodi formali, o ispezione manuale
Le
Recommendations
sono definite in base a due criteri:
1. La loro applicazione è verosimile che migiori la sicurezza,
l’affidabilità o la protezione dei sistemi software.
2. Uno o più dei requisiti da indicare come rule non possono essere
soddisfatte.
Applicazione
La formulazione delle rules è orientata verso una applicazione
automatizzata
Es.:
Rule 8.14 “i Qualifier riservati non dovranno essere utilizzati”
La formulazione delle Rules è appena più generica.
Es.:
EXP43-C: “Nell’utilizzare i puntatori
restrict-qualified
vanno evitati i
comportamenti non definiti”
Organizzazione
Per settori di linguaggio e ambiente: “The Implementation”,
“Compilation and build”, “Requirements traceability”, “Code design”,
“A standard C environment”, “Unused code”, “Comments”, “Character
sets and lexical conventions”, “Identifiers”, “Types”, “Literals and
constants”, “Declarations and definitions”, “Initialization”, “The
essential type model”, “Pointer type conversions”, “Expressions”, “Side
effects”, “Control statement expressions”, “Control flow”, “Switch
statement”, “Functions”, “Pointers and arrays”, “Overlapping storage”,
“Preprocessing directives”, “Standard libraries” and “Resources”.
Per elementi di linguaggio di basso livello: “Preprocessor (PRE)”,
“Declarations and initialization (DCL)”, “Expressions (EXP)”, “Integers
(INT)”, “Floating Point (FLP)”, “Arrays (ARR)”, “Characters and
strings (STR)”, “Memory management (MEM)”, “Input/Output
(FIO)”, “Environment (ENV)”, “Signals (SIG)”, “Error handling (ERR)”,
“Application Programming Interfaces (API)”, “Concurrency (CON)”,
“Miscellaneous (MSC)”, “POSIX (POS)”, “Microsoft Windows (WIN)”
Severity
classification
Liberamente collegato alle proprietà di “Category” della Rule:
Mandatory (nessuna deroga ammessa)
Required (deroghe consentite)
Advisory (processi di deroga formale non richiesti)
Approccio basato sulla valutazione dei rischi. Ogni linea guida ha
una
priority
come prodotto di
severity
,
likelihood
e
remediation cost
(ciascuno di essi con un valore in una scala da 1 a 3). La gamma di
priorità definisce il legame con uno dei tre livelli possibili:
L1 -> Priorities 12, 18, 27 (elevata severità)
L2 -> Priorities 6, 8, 9
L3 -> Priorities 1, 2, 3, 4 (bassa severità)
Procedura
di Deroga
Formalizzato: richiede l’indicazione della linea guida da cui si è
derogato, le circostanze in cui è consentita la deroga, la motivazione
della deroga, una valutazione del rischio derivante (dimostrazione di
come la sicurezza è ugualmente assicurata, ulteriori prove richieste
ecc.) ed è necessaria una approvazione formale.
Limitata: è possibile derogare solo da Rules di tipo Advisory e
Required.
Non c’è alcuna descrizione di un formale processo di gestione
per le deroghe, anche se sono menzionati come un modo per
sopprimere i veri e veri-positivi dimostratamente innocui o che sono
in accadimento sulle scelte architetturali non previste dallo standard.