Una vulnerabilità in un servizio presente sul dispositivo, ma non in esecuzione e non utilizzata, deve essere menzionata nel rapporto sulle vulnerabilità?

Dipende da come la tua organizzazione utilizza questo tipo di rapporti.

Se le persone responsabili della pianificazione e / o dell'implementazione dei controlli di sicurezza leggono questi documenti una volta e poi non li guardano mai più O li vedono più come linee guida rispetto alle regole attuali su come impostare un ambiente, posso vedere che potresti voglio astenermi dall'aggiungere troppe informazioni nel rapporto. Solo perché vuoi essere sicuro che le vulnerabilità presenti in modo reale siano soddisfatte con misure di sicurezza.

D'altra parte se questi sono documenti "viventi" che stabiliscono regole su come i piani devono essere pianificati e implementati E le persone che sono responsabili aggiornano questi documenti se l'infrastruttura cambia a un certo punto, si vuole sicuramente includerli vulnerabilità.

IMHO come qualcuno che organizza la sicurezza delle informazioni in un'istituzione questo è il tipo di cultura che dovresti promuovere.

Se hai paura che il tuo documento diventi troppo disordinato, puoi sempre lavorare con la sua struttura. Qualcosa che è stato fatto in un'organizzazione con cui ho lavorato è stato, che vulnerabilità come questa o possibili vulnerabilità future sono state aggiunte in un allegato al documento principale. Se l'infrastruttura è stata modificata in qualche modo, gli amministratori potrebbero controllare prima l'allegato, se una qualsiasi delle modifiche apporterebbe le vulnerabilità elencate qui.

Un ultimo punto che vorrei fare: sebbene tu non abbia abilitato queste funzionalità, questo non significa che un attaccante non lo farà dopo aver avuto accesso al router. Quindi, l'implementazione di misure di sicurezza nel caso in cui possa essere ragionevole. Questo potrebbe essere qualcosa che dovrebbe essere valutato in un'analisi di rischio però.

Per quotare ISO / IEC 27005:

The presence of a vulnerability does not cause harm in itself, as there needs to be a threat present to exploit it. A vulnerability that has no corresponding threat may not require the implementation of a control, but should be recognized and monitored for changes.

Come cliente di segnalazioni di vulnerabilità, direi di sì, ma è certamente una perdita di tempo per attribuirgli lo stesso peso delle altre vulnerabilità. Ad es., Enormi fori di accesso remoto sfruttabili o backdoor dannosi attivi non otterrebbero la stessa copertura di qualcosa come una vulnerabilità DoS o in questo caso una vulnerabilità in un bit di software disabilitato.

IMHO il rapporto dovrebbe avere un sommario esecutivo, un risultato tecnico, quindi andare nel dettaglio noioso.

Qualcosa di simile a quello che descrivi sarebbe un elemento unico nei risultati tecnici e avrai alcune informazioni nella noiosa sezione dei dettagli.

CVE-2016-6380 tuttavia significherebbe che non si aggiusta regolarmente i dispositivi o si ha un ciclo di patch molto lento. Questo potrebbe essere un rischio accettato da parte del cliente, ma dovrebbe essere esaminato. È maggio che vale la pena menzionarlo nel sommario esecutivo. Nessuna roba CVE #, i dirigenti non si preoccupano.

Vedi oltre nel NIST 800-115 7.3

...

While individual vulnerabilities need to be identified and resolved, identifying the root cause of vulnerabilities is key to improving the organization’s overall security posture because a root cause can often be traced to program-level weaknesses. Some common root causes include:

• Insufficient patch management, such as failing to apply patches in a timely fashion or failing to apply patches to all vulnerable systems

...

Prima di tutto è necessario avere una portata di ciò che si sta cercando e di cosa si sta riferendo.

Ad esempio, lo scopo della scansione è quello di scoprire e riportare tutte le vulnerabilità incluse le vulnerabilità a basso rischio o solo ad alto rischio, o solo vulnerabilità critiche. Questo dovrebbe essere stato definito prima ancora di aver avviato la scansione delle vulnerabilità.

Se è un falso positivo confermato, rimuovilo dal rapporto.

Se si tratta di un servizio presente ma non utilizzato ed è una vulnerabilità confermata nell'ambito, includerlo nel report in modo che il servizio possa essere rimosso dalla destinazione.

Se qualcuno prende una decisione di acquisto, potrebbe dire "questo router supporta la risoluzione DNS nel router. Non lo usiamo ora, ma potremmo farlo in futuro, quindi compriamo questo router e non un po 'meno uno senza la funzione ".

Tale vulnerabilità indica che il router non può essere utilizzato in questo modo, quindi la funzione non deve essere utilizzata per la decisione di acquisto. In altre parole, dovrebbe essere nel report per questo motivo. E se il servizio può essere rimosso dal dispositivo, dovrebbe essere rimosso. (Potresti scoprire che il tuo presupposto che non fosse usato era in realtà sbagliato se il servizio viene rimosso e la gente si lamenta).