Risultati
121 risultati
-
italia
9. Regolamento contabile e riversamento
Fatta salva la particolare natura del versamento in oggetto, regolato dall’articolo 4 del DPR 144/2001, per quanto riguarda le somme incassate sui conti correnti postali, in quanto somme nella disponibilità dell’Ente Creditore ha la facoltà di richiedere a Poste Italiane S.p.a. di eseguire il riversamento sul conto di tesoreria delle somme incassate attraverso il Sistema pagoPA nella singola Giornata operativa del Nodo dei Pagamenti-SPC (vedi paragrafo 8.5) mediante invio di SEPA Credit Transfer, con le modalità indicate nell’Allegato A - Specifiche attuative dei codici identificativi di versamento, riversamento e rendicontazione. All’esercizio della facoltà da parte dell’Ente Creditore corrisponde l’obbligo di Poste Italiane S.p.a. di darvi immediata esecuzione accreditando le somme con la periodicità richiesta dall’Ente Creditore, la quale, come minimo, dovrà tenere conto della tempistica di legge per l’esecuzione della duplice operazione di accredito ...
-
italia
1. Riferimenti normativi
Di seguito si riportano le norme prese a riferimento per la stesura delle presenti Linee guida:. (1) Regio decreto 23 maggio 1924, n. 827, e successive modificazioni recante “Regolamento per l’amministrazione del patrimonio e per la contabilità generale dello Stato”;. (2) Decreto legislativo 1 settembre 1993, n. 385 e successive modificazioni, recante “Testo unico delle leggi in materia bancaria e creditizia”;. (3) Decreto-legge 1° dicembre 1993, n. 487, convertito, con modificazioni, dalla legge 29 gennaio 1994, n. 71 recante “Trasformazione dell’Amministrazione delle poste e delle telecomunicazioni in ente pubblico economico e riorganizzazione del Ministero”, con riferimento all’articolo 2, comma 2 con il quale l’Ente Poste deve sottoscrivere convenzioni con gli enti pubblici al fine di regolare, tra le altre, le operazioni afferenti lo svolgimento del servizio di tesoreria;. (4) Decreto legislativo 9 luglio 1997, n. 241 e successive modificazioni recante “Norme di semplificazione degli adempimenti dei contribuenti in sede di dichiarazione dei redditi e dell’imposta sul valore aggiunto, nonché di modernizzazione del sistema di gestione delle dichiarazioni”, in particolare l’articolo 17 relativo al sistema dei versamenti unitari;. (5) Decreto legislativo 30 luglio 1999, n. 300 e successive modificazioni recante “Riforma dell’organizzazione del Governo, a norma dell’articolo 11 della legge 15 marzo 1997, n. 59”, con riferimento agli articoli 62 e 63, che regolano le funzioni delle agenzie fiscali (Agenzia delle entrate e Agenzia delle dogane e dei monopoli);. (6) Decreto legislativo 18 agosto 2000, n. 267 e successive modificazioni recante “Testo unico delle leggi sull’ordinamento degli enti locali”, in particolare ci si riferisce al Titolo V della Parte II, riguardante la gestione del servizio di tesoreria;. (7) Decreto del Presidente della Repubblica 14 marzo 2001, n.144 e successive modificazioni recante “Regolamento recante norme sui servizi di bancoposta”;. (8) Decreto legislativo 7 marzo 2005, n. 82 e successive modificazioni recante il “Codice dell’amministrazione digitale”, di seguito indicato anche come “CAD”;. (9) Decreto del Ministro dell’economia e delle finanze 9 ottobre 2006, n. 293 recante “Regolamento recante norme per l’introduzione di nuove modalità di versamento presso le tesorerie statali”;. (10) Legge 27 dicembre 2006, n. 296 recante “Disposizioni per la formazione del bilancio annuale e pluriennale dello Stato (legge finanziaria 2007)”, con riferimento all’articolo 1, comma 455 per mezzo del quale le regioni possono costituire centrali di committenza regionali;. (11) Provvedimento 20576 dell’Autorità garante della concorrenza e del mercato del 16 dicembre 2009 avente come argomento “Poste Italiane - aumento commissione bollettini c/c”;. (12) Decreto legislativo 27 gennaio 2010, n. 11 recante “Attuazione della direttiva 2007/64/CE relativa ai servizi di pagamento nel mercato interno, recante modifica delle direttive 97/7/CE, 2002/65/CE, 2005/60/CE, 2006/48/CE e che abroga la direttiva 97/5/CE”. Si precisa che l’articolo 37, comma 6 del decreto stesso ha rinviato l’applicazione alle pubbliche amministrazioni delle norme in esso contenute ad un successivo decreto del Ministro dell’economia e delle finanze, sentita la Banca d’Italia, ancora in corso di definizione: in assenza di tale normativa si ritiene opportuno precisare che le presenti Linee guida prendono comunque a riferimento le disposizioni contenute nel citato decreto legislativo 27 gennaio 2010, n.11;. (13) Provvedimento della Banca d’Italia del 5 luglio 2011 recante “Attuazione del Titolo II del Decreto legislativo n. 11 del 27 gennaio 2010 relativo ai servizi di pagamento (Diritti ed obblighi delle parti)”;. (14) Decreto-legge 13 agosto 2011, n. 138, convertito con modificazioni dalla legge 14 settembre 2011, n. 148, recante “Ulteriori misure urgenti per la stabilizzazione finanziaria e per lo sviluppo” e in particolare, l’articolo 6, comma 5 che - introducendo il comma 2-bis all’articolo 81 del CAD - ha previsto la messa a disposizione da parte dell’allora DigitPA (oggi Agenzia per l’Italia Digitale), attraverso il Sistema pubblico di connettività, “di una piattaforma tecnologica per l’interconnessione e l’interoperabilità tra le pubbliche amministrazioni e i prestatori di servizi di pagamento abilitati”;. (15) Decreto-legge 6 dicembre 2011, n. 201, convertito con modificazioni dalla legge 22 dicembre 2011, n.214, recante “Disposizioni urgenti per la crescita, l’equità e il consolidamento dei conti pubblici” e, in particolare, l’articolo 12 “Riduzione del limite per la tracciabilità dei pagamenti a 1.000 euro e contrasto all’uso del contante”;. (16) Regolamento (UE) 260/2012 del Parlamento europeo e del Consiglio del 14 marzo 2012 che stabilisce i requisiti tecnici e commerciali per i bonifici e gli addebiti diretti in euro e che modifica il regolamento (CE) n. 924/2009;. (17) Decreto-legge 18 ottobre 2012, n. 179, convertito con modificazioni dalla legge 17 dicembre 2012, n. 221, recante “Ulteriori misure urgenti per la crescita del Paese”, con particolare riferimento all’articolo 15 “Pagamenti elettronici”;. (18) Provvedimento della Banca d’Italia del 12 febbraio 2013 recante “Istruzioni applicative del Regolamento 260/2012 del Parlamento europeo e del Consiglio che stabilisce i requisiti tecnici e commerciali per i bonifici e gli addebiti diretti in euro e che modifica il Regolamento (CE) n. 924/2009 “;. (19) Legge 27 dicembre 2013, n. 147, comma 688 relativa al versamento dell’imposta municipale propria (IMU) e del tributo per i servizi indivisibili (TASI). (20) Legge 7 agosto 2015, n. 124 recante “Deleghe al Governo in materia di riorganizzazione delle amministrazioni pubbliche”, meglio conosciuta come Legge Madia di Riforma della PA;. (21) Decreto-legge 22 ottobre 2016, n. 193, convertito, con modificazioni dalla legge 1 dicembre 2016, n. 225 recante “Disposizioni urgenti in materia fiscale e per il finanziamento di esigenze indifferibili” e, in particolare, l’articolo 2-bis per il pagamento spontaneo di tributi;. (22) Decreto legislativo 13 dicembre 2017, n. 217 recante “disposizioni integrative e correttive al decreto legislativo 26 agosto 2016, n. 179, recante «Modifiche e integrazioni al Codice dell’amministrazione digitale di cui al decreto legislativo 7 marzo 2005, n 82, ai sensi dell’articolo 1 della legge 7 agosto 2015, n. 124, in materia di riorganizzazione delle amministrazioni pubbliche»”;. (23) Decreto legislativo 15 dicembre 2017, n. 218 recante “Recepimento della direttiva (UE) 2015/2366 relativa ai servizi di pagamento nel mercato interno, che modifica le direttive 2002/65/CE,2009/110/CE e 2013/36/UE e il regolamento (UE) n. 1093/2010, e abroga la direttiva 2007/64/CE, nonché adeguamento delle disposizioni interne al regolamento (UE) n. 751/2015 relativo alle commissioni interbancarie sulle operazioni di pagamento basate su carta” ...
-
italia
4. Soggetti destinatari
Ai sensi dell’articolo 5 del CAD, sono tenute ad accettare pagamenti elettronici tutte le pubbliche amministrazioni di cui all’articolo 1, comma 2, del decreto legislativo 30 marzo 2001, n. 165, i gestori di pubblici servizi, nonché le società a controllo pubblico, come definite nel decreto legislativo adottato in attuazione dell’articolo 18 della legge n. 124 del 2015, escluse le società quotate come definite dallo stesso decreto legislativo adottato in attuazione dell’articolo 18 della legge n. 124 del 2015. Inoltre, l’articolo 15, comma 5bis, del D.L. 179/2012, come convertito in legge, ha esteso genericamente alle pubbliche amministrazioni l’obbligo a collegarsi all’infrastruttura del Nodo dei Pagamenti-SPC. A tal riguardo, per la nozione di pubblica amministrazione, si rinvia a quanto già ampiamente dettagliato dal Ministero dell’Economia e delle Finanze e dalla Presidenza del Consiglio dei Ministri con la circolare interpretativa n. 1 del 9 marzo 2015, emessa per l’ambito applicativo soggettivo della fatturazione elettronica. Pertanto, nel seguito del presente documento sarà utilizzata la dizione Enti Creditori per indicare genericamente l’insieme dei soggetti obbligati all’adesione al Sistema pagoPA unitamente a quelli aderenti in via facoltativa. Le operazioni di pagamento oggetto delle presenti Linee guida afferiscono a quanto dovuto agli Enti Creditori a seguito di obblighi di legge ovvero conseguenti all’erogazione di servizi ovvero per pagamenti a qualsiasi titolo dovuti e che possono essere attivati, sia da parte dell’Ente Creditore, sia su iniziativa dell’utilizzatore finale. L’Agenzia si riserva di valutare istanze di adesione di soggetti non obbligati che vogliano aderire in via facoltativa al sistema. L’adesione resta, altresì, facoltativa da parte dei prestatori di servizi di pagamento che vogliano erogare servizi nei confronti degli utilizzatori finali ...
-
italia
8. Effettuazione del pagamento
Al fine di assicurare l’applicazione uniforme dei tempi di esecuzione massima delle operazioni e tenendo altresì conto dei diversi modelli operativi adottati dai PSP, indipendentemente dal termine della giornata operativa stabilito da ciascun PSP, il termine della giornata operativa per la ricezione delle operazioni di pagamento da effettuarsi tramite il Nodo dei Pagamenti-SPC (c.d. “giornata operativa del Nodo dei Pagamenti-SPC”) è indicata nella Sezione I dell’ Allegato A - Specifiche attuative dei codici identificativi di versamento, riversamento e rendicontazione. [3]. Capo III “Formazione, gestione e conservazione dei documenti informatici” del CAD. [4]. La commissione applicata dal PSP al pagatore rappresenta il corrispettivo per l’esecuzione di un servizio di pagamento e non costituisce pertanto una fattispecie assimilabile al surcharge (art. 3, comma 4, D.Lgs. 11/2010; art. 21, comma 4bis, e art. 62, comma 1, D.Lgs. 206/2005) in cui il beneficiario applica un sovrapprezzo per l’utilizzo di determinati strumenti di pagamento, ribaltando sull’utente, in tutto o in parte, le commissioni che lo stesso beneficiario è chiamato a riconoscere al proprio PSP ...
-
AGID
3. Indicazioni per AGID
Presidiare la tematica della sicurezza significa anche verificare che siano costantemente disponibili, per le amministrazioni, adeguati (e sicuri) strumenti di acquisizione di prodotti e servizi ICT. A tale scopo, AGID propone di tener conto anche di questo obiettivo nel pianificare, di concerto con la Consip, la tempistica delle gare che interessano sistemi e progetti critici sotto l’aspetto della sicurezza, evitando ad esempio situazioni in cui convenzioni e/o accordi quadro siano esauriti e i successivi non siano ancora disponibili perché le relative gare sono ancora da aggiudicare ...
-
AGID
1. Premessa
DR-1. ISO 22317 - Linee guida per Business Impact Analysis. https://www.iso.org/standard/50054.html. DR-2. ISO 27001 - Sistema di Gestione della Sicurezza delle Informazioni. https://www.iso.org/isoiec-27001-information-security.html. DR-3. ISO 31000 Risk Management. https://www.iso.org/iso-31000-risk-management.html. DR-4. Linee guida sviluppo software sicuro. https://www.agid.gov.it/it/sicurezza/cert-pa/linee-guida-sviluppo-del-software-sicuro. DR-5. Misure minime di sicurezza AGID. https://www.agid.gov.it/it/sicurezza/misure-minime-sicurezza-ict. DR-6. ISO 15408 Standard Common Criteria. https://www.iso.org/standard/50341.html ...
-
AGID
Linee guida sicurezza nel procurement ICT
La consultazione pubblica relativa al presente documento è attiva dal 14 maggio al 13 giugno 2019. Questo documento raccoglie il testo delle Linee guida sicurezza nel procurement ICT, disponibile per la consultazione pubblica ...
-
AGID
5. Appendice A – Requisiti di sicurezza eleggibili
Nelle tabelle che seguono sono elencati alcuni requisiti di sicurezza che le amministrazioni possono inserire nei propri capitolati di gara. L’elenco non è esaustivo, ha solo lo scopo di offrire alcuni esempi significativi e di favorire un lessico comune nell’esprimere requisiti di sicurezza. Per ragioni di sintesi, il testo di alcuni requisiti (ad esempio di R1) è stato generalizzato in modo da renderlo un modello per una “famiglia di requisiti”, da declinare ed eventualmente suddividere in più requisiti elementari, a seconda del contesto della singola acquisizione. R1. Il fornitore deve adottare al proprio interno le procedure e politiche di sicurezza definite dall’amministrazione committente, con particolare riferimento alle modalità di accesso ai sistemi dell’amministrazione, all’hardening (esempio installazione di soluzioni di end point security) dei dispositivi utilizzati dal fornitore, alla gestione dei dati dell’amministrazione. R2. Il fornitore deve possedere la certificazione ISO/IEC 27001 e mantenerla per tutta la durata della fornitura. R3. (alternativo al precedente) Anche se il fornitore non è certificato ISO/IEC 27001, almeno deve usare un Sistema di Gestione della Sicurezza delle Informazioni (SGSI) aggiornato nel tempo. R4. Il fornitore deve far eseguire annualmente un audit sul proprio sistema di sicurezza, a proprie spese e da una società specializzata scelta previa approvazione della stazione appaltante. NB: Qualora applicabile, tale attività si incrocia con il requisito R2 (le verifiche dell’Ente Certificatore hanno cadenza pressoché annuale). R5. L’amministrazione può, con un preavviso di 20 giorni solari, richiedere ulteriori attività di auditing secondo modalità concordate con il fornitore. Le risultanze di tali audit verranno comunicate all’amministrazione. R6. L’amministrazione, direttamente o tramite terzi incaricati, può eseguire verifiche relative alla conformità della prestazione dei servizi rispetto a quanto stabilito nel capitolato tecnico oltre che nell’offerta tecnica se migliorativa. R7. Il personale del fornitore che presta supporto operativo nell’ambito dei servizi di sicurezza dovrà possedere certificazione su specifici aspetti della sicurezza. R8. Il fornitore deve disporre di una struttura per la prevenzione e gestione degli incidenti informatici con il compito d’interfacciarsi con le analoghe strutture dell’amministrazione e con le strutture centrali a livello governativo. R9. Il fornitore deve dotarsi delle misure minime di sicurezza per limitare il rischio di attacchi informatici (riferimento DR-5). R10. Il SOC del fornitore deve sovrintendere alla gestione operativa e continuativa degli incidenti informatici sui servizi erogati nell’ambito della fornitura. R11. Il fornitore deve garantire il rispetto di quanto richiesto dalla normativa vigente in materia di sicurezza cibernetica, anche in riferimento ai contenuti del GDPR. R12. Sulle reti messe a disposizione dal fornitore devono essere presenti di dispositivi di sicurezza perimetrale con funzioni di sicurezza (ad esempio Firewall e sistemi di Network Detection ed Event & Log Monitoring, SIEM, ecc.) necessari a rilevare e contenere eventuali incidenti di sicurezza ICT e in grado di gestire gli IoC (Indicator of Compromise). R13. Il fornitore deve usare protocolli cifrati e meccanismi di autenticazione nell’ambito dei servizi erogati. R14. Qualora il fornitore subisca un attacco, in conseguenza del quale vengano compromessi sistemi del committente da lui gestiti, deve farsi carico delle bonifiche del caso, e riportare i sistemi in uno stato di assenza di vulnerabilità. R15. Il fornitore si impegna a trattare, trasferire e conservare le eventuali repliche dei dati oggetto di fornitura, ove autorizzate dalle amministrazioni, sempre all’interno del territorio dell’UE. R16. Il fornitore deve dare disponibilità a far parte di un Comitato di Direzione Tecnica, eventualmente aperto anche a soggetti terzi, che tratti il tema della sicurezza, sia nell’ottica di favorire la risoluzione di temi aperti sia per introdurre eventuali varianti al contratto per fronteggiare nuove minacce o altro. R17. Il fornitore deve condividere le informazioni necessarie al fine di garantire il corretto monitoraggio della qualità e della sicurezza, eventualmente pubblicando le stesse nel portale della fornitura. R18. Il fornitore si impegna a sottoscrivere una clausola di non divulgazione (NDA) sui dati e sulle informazioni dell’amministrazione. R19. Le soluzioni e i servizi di sicurezza proposti dal fornitore devono essere aggiornati dal punto di vista tecnologico, con riferimento all’evoluzione degli standard e del mercato; devono essere conformi alle normative e agli standard di riferimento applicabili; devono venire adeguati nel corso del contratto, senza oneri aggiuntivi, alle normative che l’UE o l’Italia rilasceranno in merito a servizi analoghi. R20. Il fornitore deve attenersi alla politica di sicurezza dell’amministrazione committente, con particolare riferimento all’accesso ai dati dell’amministrazione, che avverrà esclusivamente sui sistemi di sviluppo e test. R21. In fase di analisi, il fornitore deve definire le specifiche di sicurezza (non funzionali) a partire dai requisiti espressi dall’amministrazione. R22. In fase di progettazione codifica, il fornitore deve implementare le specifiche di sicurezza nel codice e nella struttura della basedati. R23. Al termine del progetto, il fornitore deve rilasciare tutta la documentazione necessaria all’amministrazione per gestire correttamente quanto rilasciato anche sotto l’aspetto della sicurezza. R24. Supporto di protocolli sicuri e cifrati (HTTPS, SSH v2, ecc.). R25. Filtraggio di indirizzi IP. R26. Supporto di protocolli di autenticazione (ad esempio RADIUS, IEEE 802.1X, ecc.). R27. Gestione di più profili con privilegi diversi. R28. Funzionalità di “richiesta creazione o cambio della password al primo accesso”. R29. Blocco dell’utenza dopo un numero definito (fisso o variabile) di tentativi falliti di accesso. R30. Gli accessi degli utenti devono essere registrati su un archivio (log) non cancellabile con il reset. R31. Gestione dei log di sistema (accessi, allarmi, ecc.). R32. Il fornitore (anche in collaborazione con il produttore della tecnologia) deve offrire processi, unità organizzative e strumenti dedicati alla gestione di vulnerabilità scoperte sui prodotti oggetto della fornitura. R33. Per gli apparati proposti deve essere disponibile documentazione tecnica (schede tecniche, manuali, guide operative) relativa alla corretta configurazione e gestione degli aspetti di sicurezza. R34. I meccanismi di autenticazione devono essere basati su meccanismi di crittografia asimmetrica, a chiave pubblica; la lunghezza delle chiavi va impostata sulla base della criticità della comunicazione da cifrare (ad esempio 256 bit per le meno critiche, 512 bit per le più critiche). La gestione e distribuzione delle chiavi e dei certificati è a carico del fornitore. R35. Autorizzazione: sulla base delle credenziali fornite dall’utente, si devono individuare i diritti e le autorizzazioni che l’utente possiede e permetterne l’accesso alle risorse limitatamente a tali autorizzazioni. R36. Confidenzialità nella trasmissione dei dati: le comunicazioni tra la componente di gestione remota centralizzata e la componente locale installata presso la sede dell’amministrazione devono essere cifrate. R37. Fornire meccanismi che permettano di garantire l’integrità di quanto trasmesso (ad esempio meccanismi di hashing). R38. Il fornitore deve descrivere nel dettaglio le soluzioni tecniche utilizzate (dispositivi hardware e software impiegato, modalità operative, politiche di sicurezza, …) per soddisfare i requisiti di sicurezza dell’amministrazione committente. R39. In fase di attivazione del servizio, il fornitore deve concordare con l’amministrazione le modalità operative e le politiche di sicurezza, i livelli di gravità degli incidenti, le attività e le contromisure che dovranno essere svolte per contrastare le minacce. R40. Il fornitore dovrà attenersi alle politiche di sicurezza definite dalla committente, con particolare riferimento alla definizione di ruoli e utenze per l’accesso ai sistemi gestiti. R41. In caso di necessità, da parte degli operatori, di accesso a Internet, il fornitore deve utilizzare un proxy centralizzato e dotato di configurazione coerente con la politica di sicurezza definita dall’amministrazione. R42. In caso di rilevazione di un incidente di gravità elevata (con scala da definire a inizio fornitura), il fornitore deve dare immediata notifica, tramite canali concordati con l’amministrazione, dell’incidente rilevato e delle azioni da intraprendere, al Responsabile della Sicurezza indicato dall’amministrazione e al CERT-PA. R43. Per ogni incidente di sicurezza, il fornitore s’impegna a consegnare all’amministrazione, entro il giorno successivo, un report che descriva la tipologia di attacco subito, le vulnerabilità sfruttate, la sequenza temporale degli eventi e le contromisure adottate. R44. Su richiesta dell’amministrazione, il fornitore deve consegnare i log di sistema generati dai dispositivi di sicurezza utilizzati, almeno in formato CSV o TXT. Tali log dovranno essere inviati all’amministrazione entro il giorno successivo a quello in cui è avvenuta la richiesta. R45. Il fornitore deve monitorare la pubblicazione di upgrade/patch/hotfix necessari a risolvere eventuali vulnerabilità presenti nei dispositivi utilizzati per erogare i servizi e nelle infrastrutture gestite. Entro il giorno successivo al rilascio dell’upgrade/patch/hotfix, il fornitore deve avviare una valutazione, da rilasciarsi entro un numero giorni da stabilirsi, propedeutica all’installazione delle stesse sui dispositivi di sicurezza, che ad esempio identifichi la possibilità di applicare la patch immediatamente, o la necessità di apportare MEV o integrazioni prima di procedere alle installazioni ...
-
AGID
4. Indicazioni per le centrali di committenza
Si premette che le indicazioni elencate nei paragrafi precedenti si applicano, in generale, anche alle centrali di committenza. In particolare, le azioni AP2, AP3 e AP4 sono da ritenersi obbligatorie, per le centrali di committenza, quando queste svolgano iniziative di acquisizione ICT nell’interesse di Ministeri, Enti centrali, Regioni e città metropolitane. In aggiunta, si ritiene che le centrali di committenza, per il ruolo che hanno nelle acquisizioni pubbliche di beni e servizi, possono fungere da enti attuatori di miglioramenti/evoluzioni per gli aspetti di sicurezza delle forniture ICT. Anche sulla base dei risultati della rilevazione citata al paragrafo precedente, si propone alle centrali di committenza di:. inserire clausole di compliance alle indicazioni in materia di sicurezza sulle gare in corso che passi attraverso anche i comitati di governo (per le gare che li prevedono);. prevedere, per le gare che comprendono gestione di sistemi o fornitura di servizi di sicurezza, non solo flussi informativi sugli eventi critici verso l’amministrazione contraente, ma anche verso il CERT-PA e gli altri organismi a presidio della sicurezza cibernetica;. per le gare che prevedono centri servizi o servizi web, qualora si ritenga applicabile la misura, verificare la sicurezza tramite vulnerability assessment e penetration test. Il governo di queste verifiche potrebbe essere a cura di un organismo centrale (CVCN, CERT-PA, altri) in collaborazione col comitato di governo della fornitura;. sensibilizzare i fornitori al fine di anticipare le tendenze e le possibili problematiche di sicurezza che possono presentarsi (consultazioni di mercato mirate alla sicurezza);. costruire, in accordo con ANAC, un elevato livello di cultura e formazione delle Commissioni di valutazione delle gare in ambito sicurezza (vedi paragrafo 2.2.4);. svolgere un ruolo di omogeneizzatore/armonizzatore degli approcci di sicurezza e delle tecnologie di sicurezza erogati nell’ambito delle forniture della PA ...
-
AGID
10. Risorse
Le facilities sono un sottoinsieme del patrimonio fisico dell’organizzazione che viene utilizzato per eseguire i servizi. Sono centri di attività in cui si intersecano molti servizi dell’organizzazione, come edifici per uffici e locali tecnici. Possono essere di proprietà dell’organizzazione ma spesso vengono noleggiate da un fornitore esterno. Le persone, le informazioni e le risorse tecnologiche «vivono» all’interno delle facilities: forniscono lo spazio fisico per le azioni delle persone (le persone lavorano negli uffici), l’uso e la memorizzazione delle informazioni (file, server) e l’operazione di componenti tecnologici (come nei data center e nelle server farm). Proprio per tale ragione è cruciale l’adozione di requisiti di sicurezza fisica ed ambientale idonei a consentire la protezione delle informazioni (si veda il Cap. 12) ...
-
AGID
6. Modello organizzativo
Ogni entità del campus è indipendente dal CERT e da tutti le altre entità che compongono la constituency. Questo modello prevede che il CERT, pur essendo distaccato, impieghi, oltre al personale assegnato in modo permanente, le risorse che le altre organizzazioni appartenenti alla constituency sono in grado di metterle a disposizione (ad esempio perché dotati di un proprio SOC) tra i membri della constituency. Il CERT erogherà i suoi servizi sia verso gli enti che forniscono le risorse, sia verso tutti gli altri membri della constituency. Fig. 6.4 Modello campus. Il modello campus è quello più adottato nei CERT di settore, tra i quali rientrano anche i CERT accademici/di ricerca e quelli militari, in quanto consente di bilanciare ottimamente le necessità di coordinamento centrale con quelle di autorità locale, come nel caso di utenti singoli o consorziati riconducibili ad uno stesso ambito professionale o caratterizzati da interessi comuni (ad esempio salute, trasporti, ecc.). Di contro, si possono considerare il modello indipendente ed incorporato come assetti più indicati per un CERT territoriale, anche in presenza di constituency caratterizzate da distribuzioni geografiche particolarmente estese, che può operare in maniera efficace sotto la supervisione dell’ente che lo ha istituito ...
-
AGID
3. Definizioni e Acronimi
Nel Glossario è riportato un elenco esaustivo di nozioni e termini utili per una corretta comprensione dei contenuti presentati all’interno di questo documento. Acronimo. Descrizione. AGID. Agenzia per l’Italia Digitale. CERT. Computer Emergency Response Team. CERT/CC. CERT/CC – CERT Coordination Center CMU-SEI. CMU-SEI. Carnegie Mellon University - Software Engineering Institute. CNAIPIC. Centro Nazionale Anticrimine Informatico per la Protezione delle Infrastrutture Critiche. CSIRT. Computer Security Incident Response Team. ENISA. Agenzia Europea per la sicurezza delle reti e dell’informazione. FIRST. Forum of Incident Response and Security Teams. IOC. Indicators of Compromise. IRPA. Incident Response Pubblica Amministrazione. ISAC. Information Sharing and Analysis Center. NATO. North Atlantic Treaty Organization. ONU. Organizzazione delle Nazioni Unite. OSCE. Organizzazione per la Sicurezza e la Cooperazione in Europa. PP.AA. Pubbliche Amministrazioni. PAC. Pubbliche Amministrazioni Centrali. PAL. Pubbliche Amministrazioni Locali. SOC. Security Operation Center. TI. Trusted Introducer ...