+Vulnerability & Patch Management Program (VPMP)
|
Vulnerability & Patch Management Program (VPMP)
Description
Mechanisms exist to facilitate the implementation and monitoring of risk-based vulnerability management capabilities.
Possible Solutions & Considerations
Micro-Small Business (<10 staff) / BLS Firm Size Classes 1-2
∙ Third-party advisors (e.g., virtual CISO, Managed Security Services Provider (MSSP), etc.)
Small Business (10-49 staff) / BLS Firm Size Classes 3-4
∙ Third-party advisors (e.g., virtual CISO, Managed Security Services Provider (MSSP), etc.)
Medium Business (50-249 staff) / BLS Firm Size Classes 5-6
∙ Vulnerability & Patch Management Program
Large Business (250-999 staff) / BLS Firm Size Classes 7-8
∙ Vulnerability & Patch Management Program
Enterprise (> 1,000 staff) / BLS Firm Size Class 9
∙ Vulnerability & Patch Management Program
SCR-CMM
Level 0 Not Performed
Practices are non-existent, based on the inability to demonstrate an implemented and operational capability. A reasonable person would conclude the control is not being performed.
Level 1 Performed Informally
Vulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:
▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.
▪ Attack Surface Management (ASM)-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.
▪ IT and/or cybersecurity personnel apply software patches through an informal process.
▪ Occasional vulnerability scanning is conducted on High Value Assets (HVAs).
▪ Vulnerability scanning services may not be internal competencies and have to be outsourced.
▪ Penetration testing services may not be internal competencies and have to be outsourced.
Level 2 Planned Tracked
Vulnerability & Patch Management (VPM) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:
▪ Policies and standards associated with VPM domain capabilities are formally documented and centrally-managed by the entity.
▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are documented and maintained by process owners.
▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with VPM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).
▪ Vulnerability management-related controls are primarily administrative and preventative in nature (e.g., policies, standards and procedures & guidelines).
▪ Vulnerability management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.
▪ IT and/or cybersecurity personnel define the breadth and depth of coverage for vulnerability scanning that covers system components scanned and types of vulnerabilities that are checked for.
▪ IT and/or cybersecurity personnel maintain a structured process to apply software patches and other vulnerability remediation efforts.
Level 3 Well Defined
Vulnerability & Patch Management (VPM) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:
▪ Policies and standards associated with VPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.
▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.
▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.
▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution and vulnerability scanning solution).
▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with VPM domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).
▪ An implemented and operational capability exists to facilitate the implementation and monitoring of vulnerability management controls.
Level 4 Quantitatively Controlled
Vulnerability & Patch Management (VPM) capabilities, in addition to being standardized across the entity and centrally managed to ensure consistency across Technology Assets, Applications, Services and/or Data (TAASD), efforts are metrics driven to provide sufficient insight for decision makers to predict optimal performance, ensure continued operations and/or identify areas for improvement. Capability criteria associated with this control reasonably expect the following criteria to exist:
▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.
▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).
▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).
▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.
▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).
▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.
▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.
Level 5 Continuously Improving
Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:
▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control.
▪ Level 5 capabilities should be considered “world-class” where the control builds on Level 4 capabilities, but are continuously improving through Artificial Intelligence (AI) and/or Machine Learning (ML) technologies.
▪ While it may be possible to develop responsive capabilities for this control through the use of AI and/or ML technologies, the criteria would be organization-specific to define.
1. Panoramica
1.1 Riferimenti
1.2 Requisiti identificati
1.3 Regolamentazioni correlate
2. Requisiti identificati
Requisiti
| Fonte |
Requisito |
3. Regolamentazioni correlate
Regolamentazioni
| Fonte |
Regolamentazione |
|
EULAW
|
Articolo 21 Misure di gestione dei rischi di cibersicurezza
-
|
|
EULAW
|
Articolo 3 Gestione dei rischi informatici
Articolo 3
Gestione dei rischi informatici
Le entità finanziarie elaborano, documentano e attuano politiche e procedure per la gestione dei rischi informatici contenenti tutti gli elementi seguenti:
a)
l’indicazione dell’approvazione del livello di tolleranza per i rischi informatici stabilito in conformità dell’articolo 6, paragrafo 8, lettera b), del regolamento (UE) 2022/2554;
b)
una procedura e una metodologia per condurre la valutazione dei rischi informatici, che identifichino:
i)
le vulnerabilità e le minacce che interessano o potrebbero interessare le funzioni commerciali supportate, i sistemi di TIC e le risorse TIC che supportano tali funzioni;
ii)
gli indicatori quantitativi o qualitativi per misurare l’impatto e la probabilità delle vulnerabilità e delle minacce di cui al punto i);
c)
la procedura per identificare, attuare e documentare le misure di trattamento dei rischi informatici per i rischi identificati e valutati, compresa la determinazione delle misure di trattamento dei rischi informatici necessarie per far rientrare il rischio informatico nel livello di tolleranza per i rischi di cui alla lettera a);
d)
per i rischi informatici residui ancora presenti dopo l’attuazione delle misure di trattamento dei rischi informatici di cui alla lettera c):
i)
disposizioni relative all’identificazione di tali rischi informatici residui;
ii)
l’assegnazione di ruoli e responsabilità per quanto riguarda:
(1)
l’accettazione dei rischi informatici residui che superano il livello di tolleranza per i rischi dell’entità finanziaria di cui alla lettera a);
(2)
il processo di riesame di cui al punto iv) della presente lettera d);
iii)
l’elaborazione di un inventario dei rischi informatici residui accettati, compresa la motivazione della loro accettazione;
iv)
disposizioni relative al riesame, almeno una volta all’anno, dei rischi informatici residui accettati, che comprendano:
1)
l’identificazione di eventuali cambiamenti nei rischi informatici residui;
2)
la valutazione delle misure di attenuazione disponibili;
3)
la valutazione della validità e dell’applicabilità, alla data del riesame, delle motivazioni che giustificano l’accettazione dei rischi informatici residui;
e)
disposizioni sul monitoraggio:
i)
di qualsiasi cambiamento nel panorama dei rischi informatici e delle minacce informatiche;
ii)
di vulnerabilità e minacce interne ed esterne;
iii)
del rischio informatico dell’entità finanziaria, che consentano di individuare tempestivamente i cambiamenti che potrebbero influire sul suo profilo di rischio informatico;
f)
disposizioni relative a un processo per garantire che si tenga conto di eventuali modifiche alla strategia aziendale e alla strategia di resilienza operativa digitale dell’entità finanziaria.
Ai fini del primo comma, lettera c), la procedura di cui a tale lettera garantisce:
a)
il monitoraggio dell’efficacia delle misure di trattamento dei rischi informatici attuate;
b)
la valutazione del raggiungimento dei livelli di tolleranza per i rischi fissati dall’entità finanziaria;
c)
la valutazione del fatto che l’entità finanziaria abbia intrapreso azioni per correggere o migliorare tali misure, ove necessario.
|
|
EULAW
|
Articolo 10 Gestione delle vulnerabilità e delle patch
-
|
|
EULAW
|
Articolo 10 Gestione delle vulnerabilità e delle patch
-
|
|
EULAW
|
Articolo 10 Gestione delle vulnerabilità e delle patch
-
|
|
EULAW
|
Articolo 10 Gestione delle vulnerabilità e delle patch
-
|
|
EULAW
|
Articolo 10 Gestione delle vulnerabilità e delle patch
-
|
|
EULAW
|
Articolo 31 Gestione dei rischi informatici
-
|
|
EULAW
|
Articolo 34 Sicurezza delle operazioni riguardanti le TIC
Articolo 34
Sicurezza delle operazioni riguardanti le TIC
Le entità finanziarie di cui all’articolo 16, paragrafo 1, del regolamento (UE) 2022/2554, nell’ambito dei loro sistemi, protocolli e strumenti e per tutte le risorse TIC:
a)
monitorano e gestiscono il ciclo di vita di tutte le risorse TIC;
b)
monitorano se le risorse TIC sono supportate da fornitori terzi di servizi TIC delle entità finanziarie, ove applicabile;
c)
identificano i requisiti di capacità delle proprie risorse TIC e le misure per mantenere e migliorare la disponibilità e l’efficienza dei sistemi di TIC e prevenire le carenze di capacità TIC prima che si concretizzino;
d)
eseguono scansioni e valutazioni automatizzate delle vulnerabilità delle risorse TIC commisurate alla loro classificazione di cui all’articolo 30, paragrafo 1, e al profilo di rischio complessivo della risorsa TIC, e applicano patch per risolvere le vulnerabilità identificate;
e)
gestiscono i rischi relativi a risorse TIC obsolete, non supportate o legacy;
f)
registrano nei log gli eventi relativi al controllo degli accessi logici e fisici, alle operazioni riguardanti le TIC, comprese le attività di sistema e di traffico di rete, e alla gestione delle modifiche delle TIC;
g)
identificano e attuano misure per monitorare e analizzare le informazioni su attività e comportamenti anomali per le operazioni essenziali o importanti riguardanti le TIC;
h)
attuano misure per monitorare le informazioni pertinenti e aggiornate sulle minacce informatiche;
i)
attuano misure per identificare possibili fughe di informazioni, codici malevoli e altre minacce alla sicurezza, nonché vulnerabilità pubblicamente note in software e hardware e verificano la disponibilità di nuovi aggiornamenti di sicurezza corrispondenti.
Ai fini della lettera f), le entità finanziarie allineano il livello di dettaglio dei log allo scopo e all’utilizzo della risorsa TIC che li produce.
|
|
EULAW
|
Articolo 9 Protezione e prevenzione
-
|
|
EULAW
|
Articolo 25 Test di strumenti e sistemi di TIC
-
|
|
EULAW
|
Articolo 9 4
4. All’interno del quadro per la gestione dei rischi informatici di cui all’articolo 6, paragrafo 1, le entità finanziarie:
|
a)
|
elaborano e documentano una politica di sicurezza dell’informazione che definisce le norme per tutelare la disponibilità, l’autenticità, l’integrità e la riservatezza dei dati, dei patrimoni informativi e delle risorse TIC, compresi quelli dei loro clienti, se del caso;
|
|
b)
|
seguendo un approccio basato sul rischio, realizzano una solida struttura di gestione della rete e delle infrastrutture impiegando tecniche, metodi e protocolli adeguati, che possono includere l’applicazione di meccanismi automatizzati, per isolare i patrimoni informativi colpiti in caso di attacchi informatici;
|
|
c)
|
attuano politiche che limitano l’accesso fisico o logico ai patrimoni informativi e alle risorse TIC unicamente a quanto è necessario per funzioni e attività legittime e approvate, e stabiliscono a tale scopo una serie di politiche, procedure e controlli concernenti i diritti di accesso e garantiscono una solida amministrazione degli stessi;
|
|
d)
|
attuano politiche e protocolli riguardanti robusti meccanismi di autenticazione, basati su norme pertinenti e sistemi di controllo dedicati, e misure di protezione delle chiavi crittografiche di cifratura dei dati sulla scorta dei risultati di processi approvati per la classificazione dei dati e la valutazione dei rischi informatici;
|
|
e)
|
attuano politiche, procedure e controlli documentati per la gestione delle modifiche delle TIC, comprese le modifiche apportate a componenti software, hardware e firmware, sistemi o parametri di sicurezza, che adottano un approccio basato sulla valutazione del rischio e sono parte integrante del processo complessivo di gestione delle modifiche dell’entità finanziaria, in modo che tutte le modifiche apportate ai sistemi di TIC siano registrate, testate, valutate, approvate, attuate e verificate in maniera controllata;
|
|
f)
|
si dotano di politiche documentate, idonee ed esaustive in materia di correzioni ed aggiornamenti.
|
Ai fini della lettera b) del primo comma, le entità finanziarie progettano l’infrastruttura di connessione di rete in modo che sia possibile isolarla o segmentarla istantaneamente, al fine di ridurre al minimo e prevenire il contagio, soprattutto per i processi finanziari interconnessi.
Ai fini della lettera e) del primo comma, il processo di gestione delle modifiche delle TIC è approvato da linee di gestione adeguate e comprende protocolli specifici in essere.
|
|
EULAW
|
Articolo 25 1
1. Il programma di test di resilienza operativa digitale di cui all’articolo 24 prevede, conformemente ai criteri di cui all’articolo 4, paragrafo 2, l’esecuzione di test adeguati, tra cui valutazione e scansione delle vulnerabilità, analisi open source, valutazioni della sicurezza delle reti, analisi delle carenze, esami della sicurezza fisica, questionari e soluzioni di scansione del software, esami del codice sorgente, ove fattibile, test basati su scenari, test di compatibilità, test di prestazione, test end-to-end e test di penetrazione.
|
|
EULAW
|
Articolo 25 2
2. I depositari centrali di titoli e le controparti centrali effettuano valutazioni della vulnerabilità prima di ciascun rilascio o nuovo rilascio di nuovi o già esistenti applicazioni e componenti infrastrutturali, e servizi TIC a supporto delle funzioni essenziali o importanti dell’entità finanziaria.
|
|
EULAW
|
Articolo 25 3
3. Le microimprese eseguono i test di cui al paragrafo 1 combinando un approccio basato sul rischio con una pianificazione strategica dei test relativi alle TIC, tenendo debitamente conto della necessità di mantenere un approccio equilibrato tra l’entità delle risorse e il tempo da assegnare ai test relativi alle TIC di cui al presente articolo, da un lato, e l’urgenza, il tipo di rischio, la criticità dei patrimoni informativi e dei servizi forniti nonché qualsiasi altro fattore rilevante, compresa la capacità dell’entità finanziaria di assumere rischi calcolati, dall’altro.
|
Ticket collegati
- Secure Controls Framework -
EN: GRCA includes the Secure Controls Framework® (SCF) content, © Secure Controls Framework Council, LLC, used under the Creative Commons Attribution-NoDerivatives 4.0 International Public License. SCF control numbers, names, descriptions and mappings appear exactly as published by the SCF Council – https://securecontrolsframework.com. GRCA may group or reorder SCF content for display, which does not change SCF content; the mappings are shown as links to the frameworks they name. Learn more at https://securecontrolsframework.com.
DE: GRCA enthält Inhalte des Secure Controls Framework® (SCF), © Secure Controls Framework Council, LLC, genutzt unter der Creative Commons Attribution-NoDerivatives 4.0 International Public License. Nummern, Namen, Beschreibungen und Zuordnungen der SCF-Controls erscheinen genau so, wie der SCF Council sie veröffentlicht – https://securecontrolsframework.com. GRCA gruppiert oder sortiert SCF-Inhalte für die Anzeige, ohne sie zu verändern; die Zuordnungen erscheinen als Verknüpfungen zu den genannten Regelwerken. Mehr unter https://securecontrolsframework.com.
|