Le aziende lavorano sistematicamente per ridurre la superficie di attacco. Segmentano le reti, gestiscono le vulnerabilit\u00e0, implementano EDR\/XDR e tentano di automatizzare le attivit\u00e0 di reazione. Per quanto paradossale possa sembrare, spesso trascurano un enorme pezzo del puzzle: la sicurezza degli stessi strumenti che gestiscono l\u2019intero sistema di difesa.<\/p>\n
Ci\u00f2 pu\u00f2 verificarsi a causa di un punto cieco mentale. \u00c8 facile presumere che, poich\u00e9 un\u2019organizzazione ha installato tutte le soluzioni di protezione necessarie, sia sicura. In realt\u00e0, qualsiasi software aggiunto (anche gli strumenti di protezione) espande la superficie di attacco. Ci\u00f2 significa che anche questi strumenti hanno bisogno di protezione e bisogna partire rafforzandoli attraverso le impostazioni corrette.<\/p>\n
Gli strumenti di protezione sono efficaci quanto il sistema che li esegue. Se un utente malintenzionato riesce a introdursi nell\u2019infrastruttura di un\u2019organizzazione e prendere il controllo della console di gestione della protezione, ha praticamente tutte le carte in regola. \u00c8 la chiave di volta per eccellenza, che consente di accedere direttamente alla gestione centralizzata dei criteri, al monitoraggio degli endpoint, alle integrazioni delle API e a tutto il resto.<\/p>\n
In questo scenario, l\u2019utente malintenzionato non deve perdere tempo a trovare modi intelligenti per aggirare le difese: \u00e8 sufficiente modificare la configurazione. Con l\u2019accesso da console, un hacker pu\u00f2 ignorare le parti difficili di una violazione:<\/p>\n
Questo \u00e8 esattamente il motivo per cui la compromissione del livello di controllo \u00e8 cos\u00ec pericolosa. Una mentalit\u00e0 proattiva alla sicurezza informatica non dipende dal numero di strumenti implementati; si tratta di quanto sia effettivamente resiliente l\u2019architettura di protezione aziendale. Se il livello di controllo \u00e8 l\u2019anello debole, nessuna quantit\u00e0 di software hi-tech pu\u00f2 attenuare tale rischio.<\/p>\n
Sulla carta, la maggior parte dei sistemi di gestione della protezione dispone gi\u00e0 di tutti i meccanismi necessari per potenziare la protezione. Il problema? Queste misure di potenziamento (anche elementi di base come l\u2019autenticazione a due fattori) sono spesso disponibili ma non obbligatorie. I consigli per la sicurezza vengono pubblicati, ma non sempre vengono implementati in modo coerente. A volte vengono semplicemente ignorati. Ancora peggio, le impostazioni di protezione critiche attivate per impostazione predefinita spesso possono essere disabilitate con un solo clic, diffondendo istantaneamente la modifica a ogni utente. E siamo onesti: le persone spesso disabilitano queste funzionalit\u00e0 in nome della praticit\u00e0.<\/p>\n
Nel mondo reale, ci\u00f2 significa che la sicurezza aziendale finisce per fare affidamento sulla disciplina personale di un amministratore. Ma la disciplina non pu\u00f2 fungere da meccanismo di difesa architettonica.<\/p>\n
L\u2019approccio moderno alla protezione del livello di controllo si sta spostando verso un modello protetto per impostazione predefinita. In questa configurazione, le protezioni critiche sono integrate nella configurazione di base e la possibilit\u00e0 di disattivarle a livello globale \u00e8 limitata. In sostanza, la protezione smette di essere una funzionalit\u00e0 opzionale.<\/p>\n
Si tratta di eliminare le congetture dalla sicurezza degli strumenti difensivi e ridurre la superficie di attacco a livello di gestione.<\/p>\n
I nostri prodotti si stanno orientando in modo coerente verso un modello in cui i meccanismi di protezione critici sono parte dell\u2019architettura di base anzich\u00e9 una funzionalit\u00e0 opzionale. Di recente \u00e8 stata rilasciata una nuova versione (16.1) di Kaspersky Security Center Linux, in cui questo cambiamento dell\u2019architettura \u00e8 integrato nei suoi principi fondamentali, principalmente il rafforzamento del controllo degli accessi alla console. Adesso l\u2019autenticazione a due fattori \u00e8 abilitata per impostazione predefinita e la possibilit\u00e0 di disabilitarla a livello globale \u00e8 stata rimossa. Prima di eseguire l\u2019upgrade, gli amministratori devono assicurarsi che la 2FA sia abilitata per tutti gli utenti, inclusi quelli che lavorano tramite la console Web o utilizzano l\u2019automazione OpenAPI.<\/p>\n
Questo stabilisce una protezione fondamentale per l\u2019accesso privilegiato a livello di console. Riduce il rischio di violazione degli account amministrativi, protegge i canali di automazione, riduce la probabilit\u00e0 di abusi delle API ed elimina le vulnerabilit\u00e0 derivanti dall\u2019utilizzo della protezione opzionale. In questo modo, la potenziale superficie di attacco viene ridotta in particolare a livello di controllo di gestione.<\/p>\n
Tuttavia, come accennato in precedenza, il problema con la maggior parte delle console e dei sistemi di gestione non \u00e8 la mancanza di funzionalit\u00e0 di protezione, ma la mancanza di un controllo sistematico sul modo in cui vengono utilizzate. Ad esempio, vediamo spesso amministratori con privilegi eccessivi o impostazioni di connessione al server di amministrazione non sicure. \u00c8 gi\u00e0 stata fornita una guida per il potenziamento<\/a> di Kaspersky Security Center che tratta in dettaglio questi problemi, ma purtroppo non tutti si prendono il tempo di leggere approfonditi manuali tecnici.<\/p>\n Ecco perch\u00e9, per assicurarci che i punti chiave non vengano ignorati, abbiamo creato un elenco di controllo strutturato<\/a> per l\u2019hardening di Kaspersky Security Center Linux, ver. 16.1. Questo elenco di controllo:<\/p>\n In sostanza, si tratta di uno strumento per una verifica sistematica del livello di controllo. Garantisce che la console non diventi un punto di ingresso o uno strumento per consentire agli utenti malintenzionati di spostarsi lateralmente nell\u2019infrastruttura. Minore \u00e8 il numero di impostazioni critiche lasciate a discrezione dell\u2019utente, minore \u00e8 anche il rischio di errore o compromissione.<\/p>\n L\u2019autenticazione avanzata e l\u2019hardening strutturato di Administration Console non sono solo piccole modifiche; rappresentano un approccio pi\u00f9 completo alla gestione della protezione. Abbiamo in programma di continuare a sviluppare questo livello di protezione, riducendo la superficie di attacco non solo a livello di endpoint, ma all\u2019interno del sistema di gestione stesso. \u00c8 possibile ottenere ulteriori informazioni su Kaspersky Security Center nella pagina della console<\/a> e la checklist dell\u2019hardening della protezione \u00e8 disponibile nel sito dell\u2019assistenza tecnica<\/a>.<\/p>\n\n","protected":false},"excerpt":{"rendered":" La protezione di una console di sicurezza \u00e8 pi\u00f9 critica di quanto si possa pensare. Ecco le informazioni dettagliate sulla compromissione del livello di controllo e su come evitare che accada.<\/p>\n","protected":false},"author":2782,"featured_media":30636,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[2364,2955,2956],"tags":[739,941,67],"class_list":{"0":"post-30633","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-business","8":"category-enterprise","9":"category-smb","10":"tag-impostazioni","11":"tag-prodotti","12":"tag-suggerimenti"},"hreflang":[{"hreflang":"it","url":"https:\/\/www.kaspersky.it\/blog\/security-console-hardening\/30633\/"},{"hreflang":"en-in","url":"https:\/\/www.kaspersky.co.in\/blog\/security-console-hardening\/30382\/"},{"hreflang":"en-ae","url":"https:\/\/me-en.kaspersky.com\/blog\/security-console-hardening\/25432\/"},{"hreflang":"en-gb","url":"https:\/\/www.kaspersky.co.uk\/blog\/security-console-hardening\/30230\/"},{"hreflang":"es","url":"https:\/\/www.kaspersky.es\/blog\/security-console-hardening\/32032\/"},{"hreflang":"ru","url":"https:\/\/www.kaspersky.ru\/blog\/security-console-hardening\/41672\/"},{"hreflang":"tr","url":"https:\/\/www.kaspersky.com.tr\/blog\/security-console-hardening\/14490\/"},{"hreflang":"x-default","url":"https:\/\/www.kaspersky.com\/blog\/security-console-hardening\/55577\/"},{"hreflang":"pt-br","url":"https:\/\/www.kaspersky.com.br\/blog\/security-console-hardening\/24929\/"},{"hreflang":"ru-kz","url":"https:\/\/blog.kaspersky.kz\/security-console-hardening\/30512\/"},{"hreflang":"en-au","url":"https:\/\/www.kaspersky.com.au\/blog\/security-console-hardening\/36118\/"},{"hreflang":"en-za","url":"https:\/\/www.kaspersky.co.za\/blog\/security-console-hardening\/35770\/"}],"acf":[],"banners":"","maintag":{"url":"https:\/\/www.kaspersky.it\/blog\/tag\/impostazioni\/","name":"impostazioni"},"_links":{"self":[{"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/posts\/30633","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/users\/2782"}],"replies":[{"embeddable":true,"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/comments?post=30633"}],"version-history":[{"count":3,"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/posts\/30633\/revisions"}],"predecessor-version":[{"id":30637,"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/posts\/30633\/revisions\/30637"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/media\/30636"}],"wp:attachment":[{"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/media?parent=30633"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/categories?post=30633"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/tags?post=30633"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}\n