5. Writing Security Considerations Sections (Redigere le sezioni sulle considerazioni di sicurezza)
5. Writing Security Considerations Sections (Redigere le sezioni sulle considerazioni di sicurezza)
Sebbene non sia un requisito che un dato protocollo o sistema sia immune a tutte le forme di attacco, è comunque necessario che gli autori considerino quante più forme possibile. Parte dello scopo della sezione Security Considerations è spiegare quali attacchi sono fuori ambito e quali contromisure possono essere applicate per difendersi da essi. Inoltre, dovrebbe esserci una descrizione chiara dei tipi di minacce sul protocollo o la tecnologia descritti. Ciò dovrebbe essere affrontato come uno sforzo di "due diligence" nel descrivere tutti i rischi e le minacce noti o prevedibili per potenziali implementatori e utenti.
Gli autori DEVONO descrivere:
- quali attacchi sono fuori ambito (e perché!)
- quali attacchi sono nell’ambito
- 2.1 e il protocollo è suscettibile a
- 2.2 e il protocollo protegge da
Almeno le seguenti forme di attacco DEVONO essere considerate: intercettazione passiva (eavesdropping), replay, inserimento, cancellazione, modifica di messaggi e man-in-the-middle. Potenziali attacchi di negazione del servizio DEVONO essere identificati altrettanto. Se il protocollo incorpora meccanismi di protezione crittografica, dovrebbe essere chiaramente indicato quali porzioni dei dati sono protette e quali sono le protezioni (cioè solo integrità, riservatezza e/o autenticazione degli estremi, ecc.). Dovrebbe essere data anche qualche indicazione su quali tipi di attacchi la protezione crittografica è suscettibile. I dati che dovrebbero essere tenuti segreti (materiale di chiave, semi casuali, ecc.) dovrebbero essere chiaramente etichettati.
Se la tecnologia coinvolge autenticazione, in particolare autenticazione utente-host, la sicurezza del metodo di autenticazione DEVE essere chiaramente specificata. Cioè, gli autori DEVONO documentare le assunzioni su cui si basa la sicurezza di questo metodo di autenticazione. Ad esempio, nel caso del metodo di login UNIX nome utente/password, una dichiarazione del tipo:
L’autenticazione nel sistema è sicura solo nella misura in cui è difficile indovinare o ottenere una password ASCII lunga al massimo 8 caratteri. Queste password possono essere ottenute intercettando sessioni telnet o eseguendo il programma crack usando il contenuto del file /etc/passwd. I tentativi di protezione contro l’indovinamento online della password mediante (1) disconnessione dopo diversi tentativi di login falliti e (2) attesa tra prompt di password successivi sono efficaci solo nella misura in cui gli attaccanti sono impazienti.
Poiché il file /etc/passwd mappa nomi utente a user id, gruppi, ecc., deve essere leggibile da tutti. Per consentire questo uso ma rendere più difficile eseguire crack, il file è spesso suddiviso in /etc/passwd e un file password shadow. Il file shadow non è leggibile da tutti e contiene la password cifrata. Il file /etc/passwd regolare contiene una password fittizia al suo posto.
Non è sufficiente dichiarare semplicemente che il proprio protocollo dovrebbe essere eseguito su qualche protocollo di sicurezza di livello inferiore. Se un sistema si affida ai servizi di sicurezza di livello inferiore per la sicurezza, le protezioni che tali servizi sono tenuti a fornire DEVONO essere chiaramente specificate. Inoltre, devono essere specificate le proprietà risultanti del sistema combinato.
Nota: In generale, l’IESG non approverà protocolli standards track che non prevedano forte autenticazione, sia interna al protocollo sia tramite legame stretto a un protocollo di sicurezza di livello inferiore.
L’ambiente di minaccia affrontato dalla sezione Security Considerations DEVE includere al minimo il dispiegamento su Internet globale attraverso più confini amministrativi senza assumere che i firewall siano in posto, anche solo per fornire giustificazione del perché tale considerazione è fuori ambito per il protocollo. Non è accettabile discutere solo minacce applicabili alle LAN e ignorare l’ambiente di minaccia più ampio. Tutti i protocolli IETF standards track sono considerati probabili per il dispiegamento su Internet globale. In alcuni casi, potrebbe esserci un Applicability Statement che scoraggia l’uso di una tecnologia o protocollo in un particolare ambiente. Ciononostante, le questioni di sicurezza del dispiegamento più ampio dovrebbero essere discusse nel documento.
Dovrebbe esserci una descrizione chiara del rischio residuo per l’utente o l’operatore di quel protocollo dopo che la mitigazione della minaccia è stata dispiegata. Tali rischi possono derivare da compromissione in un protocollo correlato (ad esempio, IPsec è inutile se la gestione delle chiavi è stata compromessa), da implementazione errata, compromissione della tecnologia di sicurezza usata per la riduzione del rischio (ad esempio, un cifrario con chiave a 40 bit), o possono esserci rischi non affrontati dalla specifica del protocollo (ad esempio, attacchi di negazione del servizio su un protocollo di collegamento sottostante). Particolare cura dovrebbe essere presa in situazioni in cui la compromissione di un singolo sistema comprometterebbe un intero protocollo. Ad esempio, in generale i progettisti di protocolli assumono che i sistemi finali siano inviolati e non si preoccupano dell’attacco fisico. Tuttavia, in casi (come un’autorità di certificazione) in cui la compromissione di un singolo sistema potrebbe portare a compromissioni diffuse, è appropriato considerare anche la sicurezza dei sistemi e fisica.
Dovrebbe esserci anche qualche discussione dei potenziali rischi di sicurezza derivanti da possibili applicazioni errate del protocollo o della tecnologia descritti nell’RFC. Ciò potrebbe essere accoppiato con un Applicability Statement per quell’RFC.