Risultati
98 risultati
-
AGID
Glossario
Le definizioni precedentemente fornite sono state individuate a partire dall’analisi delle seguenti fonti:. AGID, Linee Guida per il Disaster Recovery delle Pubbliche Amministrazioni. AGID, Linee Guida per la razionalizzazione dei CED delle Pubbliche Amministrazioni. AGID, Linee Guida sulla qualità dei beni e dei servizi ICT per la definizione ed il governo dei contratti della Pubblica Amministrazione. Codice in materia di protezione dei dati personali (Codice «Privacy»). Codice in materia di protezione dei dati personali (Codice «Privacy»), Allegato «B». Cyber Security Report La Sapienza. ENISA, Un approccio graduale alla creazione di un CSIRT, Documento WP2006/5.1(CERT-D1/D2). FIRST. Garante per la protezione dei dati personali. Glossario CERT-Nazionale. Glossario CERT-PA. Glossario ENISA. Glossario OWASP. ISACA, Cybersecurity Fundamentals Glossary. ISO 22300:2012, Security and resilience – Vocabulary. ISO 31000:2018, Risk management – Guidelines. ISO/IEC 20000-1:2011, Part 1: Service management system requirements. ISO/IEC 27000:2018, Information security management systems – Overview and vocabulary. ISO/IEC 27032:2012, Guidelines for cybersecurity. ISO/IEC 27035-1:2016, Information security incident management – Part 1: Principles of incident management. NIST SP 800-145, The NIST Definition of Cloud Computing. NIST SP 800-150, Guide to cyber threat information sharing. NIST SP 800-34 Rev. 1, Contingency Planning Guide for Federal Information Systems. NISTIR 7298 Revision 2, Glossary of Key Information Security Terms. Quadro strategico nazionale per la sicurezza dello spazio cibernetico. Regolamento generale per la protezione dei dati personali n. 2016/679 (General Data Protection Regulation o GDPR). SANS Glossary of Security Terms. The Institute of Risk Management. The MITRE Corporation. US Department of Homeland Security, NICCS - National Initiative for Cybersecurity Careers and Studies ...
-
italia
Policy del catalogo del software open source di Developers Italia
Regole per la pubblicazione di software nel catalogo di Developers Italia. Questo documento si pone l’obiettivo di rendere più trasparente e condivisa la modalità di valutazione del software candidato ad entrare nel catalogo di Developers Italia ...
-
italia
Ammissione del software a catalogo
Nel catalogo del software di Developers Italia non sono ammessi:. I repository ospitati in uno strumento di code hosting non conforme ai requisiti espressi nell’allegato A delle linee guida. I repository che contengono:. software incompleto;. software non compilabile / installabile;. software privo di documentazione relativa alla compilazione o all’installazione;. software che non rientra nella definizione di cui all’art. 1.2 delle linee guida;. software che non raggiunge un livello sufficiente di unità funzionale. I repository che violano delle regole di diritto:. software privi di licenza aperta;. repository contenenti licenze tra loro incompatibili;. software che violano diritti di proprietà intellettuale o altri diritti di terzi;. repository con contenuti illegali, commerciali o che violano norme di legge. I repository contenenti un file publiccode.yml non valido:. non rispondente alle specifiche (descritte qui);. che non permette di capire lo scopo, le finalità e i requisiti del software;. I gestori della piattaforma Developers Italia si riservano il diritto di rimuovere dal catalogo i repository che violano queste regole. In caso di esclusione i gestori della piattaforma Developers Italia comunicheranno le motivazioni al gestore del repository attraverso i canali di comunicazione disponibili. A seguito della eventuale correzione delle violazioni segnalate e della relativa comunicazione ai gestori di Developers Italia, il software potrà essere incluso nuovamente nel catalogo ...
-
italia
Il Catalogo di Developers Italia
La seguente policy si applica all’inserimento di soluzioni software open source all’interno del catalogo di Developers Italia. Il catalogo di Developers Italia contiene due aree:. La seconda è dedicata a soluzioni open source, la cui titolarità sia attribuita a soggetti terzi, che potrebbero essere di interesse di una PA. L’aggiunta di software al catalogo avviene in automatico tramite una scansione periodica notturna di diverse fonti:. Gli spazi di code hosting inseriti attraverso una procedura di Pull Request nel file di whitelist presente sul repo GitHub. Questi software entrano nella seconda area del catalogo (B). Altri spazi di code hosting individuati dai gestori del catalogo di Developers Italia con mezzi manuali o automatizzati. Questi software entrano nella seconda area del catalogo (B) ...
-
italia
Limitazione di responsabilità
AgID e il Team per la Trasformazione Digitale non sono responsabili per il software pubblicato, per la sua rispondenza alle normative e per la sua sicurezza. L’acquisizione e la messa in opera di tale software avvengono sotto la responsabilità di ciascun ente secondo le disposizioni e le limitazioni di responsabilità indicate nella relativa licenza. L’inclusione delle soluzioni nel catalogo avviene con mezzi automatizzati come sopra descritto e pertanto i gestori della piattaforma Developers Italia non svolgono attività di verifica preventiva ...
-
AGID
12. Modelli di analisi e valutazione dei risultati raggiunti
Volume di informazioni prodotte dal CERT (avvisi, bollettini, rapporti). Numero di accessi alle informazioni fornite dal CERT. Numero di richieste raccolte dalla constituency. Quantità di informazioni presentate alla propria constituency su tematiche di cyber security o sulle attività in corso. Perdite monetarie totali derivanti da attacchi cyber subite dalla constituency servita dal CERT (normalizzate rispetto alle dimensioni della constituency). Capacità di offrire servizi in termini di numero e/o qualità rispetto ai propri peer (ciò può essere misurato sia effettuando la valutazione rispetto a standard o best practice di settore, sia effettuando una misurazione comparativa dei risultati dei peer in situazioni analoghe). Disponibilità di finanziamenti sufficienti. Numero totale di membri dello staff. Assegnazione tra i membri dello staff di esperti legali e di comunicazione specializzati. Assegnazione di personale specializzato in discipline tecniche (analisi del codice, analisi forense, ecc.). Livelli di istruzione / formazione dei membri dello staff. Frequenza e qualità della formazione interna su aspetti tecnici specialistici. Numero di esercitazioni cyber condotte dal CERT internamente. Livello di conformità dei processi e delle procedure del CERT a standard e specifiche normative (può essere determinato attraverso l’ottenimento di certificazioni o attività di audit). Capacità di proteggere la confidenzialità dei dati e delle informazioni durante le proprie operazioni (ad esempio durante il processo di gestione di un incidente). Livello di utilizzo delle risorse del CERT rispetto alla sua effettiva capacità (si noti come un elevato utilizzo delle risorse possa portare da un lato a tempi di risposta migliori e/o indicare una migliore allocazione, mentre dall’altro il pieno utilizzo potrebbe essere un indicatore del raggiungimento della capacità massima con possibili ripercussioni nella capacità di erogare altri servizi). Capacità del CERT di stabilire canali di comunicazione che permettono una trasmissione efficiente dei dati e delle informazioni (sia verso l’interno che verso l’esterno). Livello di soddisfazione della constituency (customer satisfaction), determinabile attraverso survey e questionari. Capacità del CERT di effettuare le proprie operazioni senza necessità di supporto esterno (un eccessivo ricorso a capacità esterne potrebbe essere un indicatore di risorse inadeguate o insufficienti a supporto dei servizi) ...
-
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) ...