Domande frequenti

La Fondazione LibreKAT lavora sulla sicurezza delle informazioni aperta, controllabile e verificabile. La fondazione sostiene progetti, condivisione di conoscenze e collaborazione sulla sicurezza digitale.

Non si tratta solo di software. LibreKAT vuole anche contribuire a migliori pratiche lavorative, maggiore trasparenza e una comunità in cui le persone possano migliorare insieme la sicurezza digitale.

Ulteriori informazioni su Informazioni sulla Fondazione LibreKAT.

La sicurezza digitale è troppo importante per dipendere completamente da sistemi chiusi, processi incontrollabili o promesse vaghe. Le organizzazioni devono essere in grado di comprendere, controllare e migliorare il funzionamento della loro sicurezza.

LibreKAT esiste per promuoverlo. La fondazione incoraggia la tecnologia aperta, la condivisione delle conoscenze e la collaborazione tra le persone che desiderano aumentare la resilienza digitale.

Leggi anche Quali sono gli obiettivi della Fondazione LibreKAT? e Informazioni sulla Fondazione LibreKAT.

No. LibreKAT è una fondazione e non ha alcun obiettivo di lucro. La fondazione può collaborare con aziende, governi, ricercatori, volontari e organizzazioni sociali.

L’obiettivo principale della collaborazione è contribuire a una sicurezza digitale aperta, sostenibile e verificabile.

Ulteriori informazioni su Informazioni sulla Fondazione LibreKAT.

Libre si riferisce alla libertà. Non solo libero utilizzo, ma soprattutto libertà di studiare, controllare, adattare e condividere la tecnologia.

Questo è importante per la sicurezza delle informazioni. Se vuoi fare affidamento su un sistema o un metodo, devi essere in grado di vedere come funziona e come vengono prese le decisioni.

Questo si ricollega a valori fondamentali della Fondazione LibreKAT.

La Fondazione LibreKAT vuole migliorare la sicurezza digitale incoraggiando una sicurezza delle informazioni aperta, controllabile e verificabile.

In termini concreti, ciò include:

• sviluppo e utilizzo di software e hardware open source per infrastrutture digitali sicure;
• trasparenza e riproducibilità nei processi di sicurezza;
• ricerca, formazione e attività sulla resilienza digitale;
• connessione tra cittadini, imprese, governo e organizzazioni sociali.

Ulteriori informazioni su Informazioni sulla Fondazione LibreKAT e su homepage della Fondazione LibreKAT.

LibreKAT è la base. OpenKAT è un prodotto di analisi delle vulnerabilità open source.

I nomi sono simili, ma non significano la stessa cosa. La fondazione può supportare OpenKAT e OpenKAT si adatta alla missione di LibreKAT, ma OpenKAT non è la fondazione stessa.

Ulteriori informazioni su Fondazione LibreKAT e OpenKAT.

L’open source rende possibile il controllo. Le persone possono vedere come funziona il software, trovare errori, suggerire miglioramenti e ridurre la dipendenza da un unico fornitore.

L’open source non è una garanzia automatica di sicurezza. Si tratta di una condizione importante per la trasparenza, la cooperazione e la ripristinabilità.

Ulteriori informazioni sui principi su Informazioni sulla Fondazione LibreKAT.

Progetti importanti su questo sito sono OpenKAT, MIAUW e OciDeck.

OpenKAT aiuta a rendere visibili le vulnerabilità e i rischi digitali. MIAUW aiuta a rendere la ricerca sulla sicurezza delle informazioni verificabile e meritevole di audit. OciDeck aiuta con presentazioni strutturate, report e condivisione sicura delle informazioni.

Ulteriori informazioni su OpenKAT, MIAUW e OciDeck.

LibreKAT è per tutti coloro che vogliono rendere la sicurezza digitale aperta, verificabile e più spiegabile.

Pensa ai professionisti della sicurezza, agli sviluppatori, agli amministratori, ai revisori, ai ricercatori, ai governi, alle aziende, alle istituzioni educative, alle organizzazioni sociali e ai cittadini coinvolti.

Ulteriori informazioni su Informazioni sulla Fondazione LibreKAT.

SÌ. Puoi partecipare in diversi modi: contribuendo con il codice, migliorando la documentazione, testando, traducendo, ponendo domande, condividendo esperienze o aiutando con riunioni e attività della comunità.

Non è necessario sapere tutto tecnicamente per dare un contributo prezioso. Sono importanti anche buone domande, esperienza pratica e spiegazioni chiare.

Contattaci all’indirizzo Contatto.

Ciò è possibile se la collaborazione risponde agli obiettivi della fondazione. LibreKAT è alla ricerca di una collaborazione che contribuisca a una sicurezza digitale aperta, sostenibile e verificabile.

Esempi sono la condivisione delle conoscenze, la ricerca, lo sviluppo open source, la documentazione, la formazione o le applicazioni pratiche dei progetti.

Vedi anche Partner e Contatto.

Valori importanti sono la sicurezza, la libertà, l’apertura, la sovranità, l’integrità, la condivisione della conoscenza, la cooperazione, l’umanità e la continuità.

In parole povere: LibreKAT vuole che la sicurezza digitale sia verificabile, equa, sostenibile e utilizzabile per le persone e le organizzazioni che dipendono da essa.

Leggi anche l’articolo Sui nostri valori fondamentali.

Utilizza pagina dei contatti se hai una domanda, vuoi contribuire o discutere di una collaborazione.

Prova a descrivere brevemente di cosa tratta la tua domanda: fondazione, MIAUW, OpenKAT, OciDeck, collaborazione, stampa o un contributo tecnico. Allora sarà più chiaro e più velocemente chi può rispondere.

Una cultura giusta è una cultura organizzativa in cui le persone possono segnalare problemi di sicurezza, errori e quasi incidenti senza cercare automaticamente qualcuno da incolpare. L’organizzazione utilizza le informazioni per capire cosa è successo e per migliorare le persone, la tecnologia, i metodi di lavoro e l’organizzazione.

Ciò non significa che ogni comportamento sia accettabile. Una cultura giusta chiarisce in anticipo dove si trovano i confini e valuta il comportamento con attenzione, coerenza e nel contesto. Le norme aeronautiche europee definiscono questa come una cultura in cui i dipendenti non vengono puniti per azioni coerenti con la loro formazione ed esperienza, mentre la negligenza grave e le violazioni intenzionali non sono tollerate. Vedi Regolamento (UE) 376/2014.

L’elaborazione moderna deriva dalla scienza della sicurezza che circonda le organizzazioni complesse e ad alto rischio. Lo psicologo James Reason ha descritto Just Culture nel 1997 come parte di una cultura della sicurezza informata, oltre a una cultura della segnalazione, una cultura dell’apprendimento e una cultura flessibile.

È soprattutto l’aviazione a mettere in pratica questo principio. Gli incidenti e i quasi incidenti possono essere indagati solo quando piloti, controllori del traffico aereo, tecnici e altri osano condividere informazioni. Le organizzazioni aeronautiche hanno quindi sviluppato sistemi di segnalazione che non puniscono automaticamente gli errori comuni, ma stabiliscono limiti per comportamenti intenzionali o sconsiderati. SKYbrary descrive questo sviluppo; l’Unione Europea ha stabilito il principio nel norme per la segnalazione di eventi nell’aviazione civile nel 2014.

Successivamente, Just Culture è stata applicata anche nel settore sanitario, ferroviario, energetico e in altri settori in cui è importante imparare dai segnali deboli. Non si tratta quindi di una procedura aeronautica da copiare individualmente, ma di un principio più ampio per affrontare errori e rischi in modo equo e orientato all’apprendimento.

No. Una cultura giusta impedisce che una segnalazione onesta, un semplice errore o una violazione involontaria portino automaticamente a una punizione. Potrebbero essere necessari coaching, supporto aggiuntivo o un metodo di lavoro adattato; Si tratta di misure per garantire un lavoro sicuro, non di sanzioni automatiche.

In caso di condotta scorretta intenzionale, sabotaggio, imprudenza deliberata o grave inosservanza di un rischio evidente, può essere appropriata un’azione contro una persona. Ciò richiede innanzitutto un’indagine onesta di fatti, circostanze, formazione, risorse disponibili e decisioni precedenti comparabili. Anche Just Culture non garantisce l’immunità legale: la legge applicabile continua ad applicarsi. Questo saldo può essere trovato in Articolo 16 del Regolamento (UE) 376/2014.

No. Un modello completamente “senza colpa” può escludere responsabilità e comportamenti inaccettabili dal quadro. Just Culture cerca un giusto confine tra il comportamento da cui l’organizzazione deve imparare e il comportamento da cui dovrebbe rivolgersi a una persona.

La prima domanda non è ‘chi possiamo punire?’, ma ‘cosa è successo, perché questa azione sembrava logica in quel momento e quali circostanze hanno avuto un ruolo?’. Solo allora sorge la questione se il comportamento rientrasse nei limiti precedentemente noti e applicati in modo coerente.

No. I dipendenti restano responsabili di agire con attenzione, riferire e collaborare alle indagini. I manager sono responsabili di obiettivi realistici, risorse sufficienti, confini chiari e risoluzione dei problemi strutturali.

Responsabilità significa che le scelte e le circostanze possono essere discusse e controllate. Attribuire la colpa è un giudizio sulla colpevolezza. Una cultura giusta separa le due cose, in modo che la responsabilità non scompaia ma sia distribuita in modo più equo.

L’errore umano non è intenzionale. Un comportamento rischioso può sorgere perché qualcuno sottovaluta un rischio, un’abitudine pericolosa è diventata normale o gli obiettivi sono in conflitto tra loro. Una condotta imprudente implica una consapevole e grave disattenzione di un rischio evidente. Le azioni intenzionalmente dannose costituiscono ancora un’altra categoria.

Queste parole non sono risultati automatici. Un’indagine attenta esamina la formazione, le informazioni disponibili, il carico di lavoro, la progettazione tecnica, le procedure, i segnali precedenti e il modo in cui altri hanno agito nella stessa situazione. La sola gravità del danno non dimostra che il comportamento sia stato imprudente.

I dipendenti sono tenuti a segnalare tempestivamente errori, rischi e quasi incidenti, a esprimere incertezze, a collaborare nella ricerca e a condividere le conoscenze rilevanti. Ci si aspetta che i manager ascoltino senza giudizi prematuri, proteggano i giornalisti, indaghino sui fatti e sul contesto e forniscano feedback su ciò che accade a una segnalazione.

L’organizzazione dovrebbe riparare le cause strutturali, trattare allo stesso modo casi comparabili e chiarire in anticipo quali comportamenti sono inaccettabili. Nascondere, vendicarsi, giudicare solo il risultato o permettere che i rischi noti continuino non rientrano in una cultura giusta.

La sicurezza delle informazioni dipende dai primi segnali. Pensa a un collegamento di phishing aperto, un accesso configurato in modo errato, un file quasi trapelato, una soluzione di emergenza non sicura o una vulnerabilità che qualcuno scopre accidentalmente. Il timore di sanzioni o di danni alla reputazione può far sì che tali informazioni vengano comunicate troppo tardi o non vengano comunicate affatto.

Una cultura giusta abbassa tale soglia e consente indagini e recuperi più rapidi. Ciò non sostituisce le misure di sicurezza, la risposta agli incidenti, gli obblighi di segnalazione o le azioni contro gli abusi. Garantisce che l’organizzazione riceva informazioni più affidabili per utilizzare tali strumenti in modo mirato.

Le persone lavorano rispettando obiettivi, strumenti, procedure, vincoli di tempo e limitazioni tecniche. Se più persone possono commettere lo stesso errore, rivolgersi solo all’ultima persona non è una soluzione completa. Le stesse condizioni possono quindi causare nuovamente il problema.

Pertanto, una cultura giusta esamina anche la progettazione del sistema, i diritti di accesso, la formazione, il carico di lavoro, la supervisione, gli obiettivi contrastanti e i segnali precedenti. Ciò non esclude la responsabilità individuale. Impedisce che un’azione umana visibile nasconda alla vista le cause più profonde.

Un pen test può influenzare il comportamento di dipendenti, amministratori o fornitori. MIAUW richiede che una scoperta sia corroborata da prove, portata e contesto. Un rapporto dovrebbe quindi descrivere fatti e conseguenze osservabili e non attribuire intenzioni o colpe personali senza indagini.

Just Culture aiuta a utilizzare i risultati per il recupero: quali condizioni tecniche o organizzative hanno reso possibile il problema, quale misura riduce la recidiva e chi possiede quella misura? Se l’azione individuale sembra appropriata, ciò richiede un processo separato ed equo; il punteggio del pen test da solo non ne è la prova.

Descrivi innanzitutto cosa è accaduto in modo dimostrabile, quando, in quale ambito e con quali conseguenze. Quindi registrare le circostanze rilevanti, come le informazioni disponibili, le istruzioni, il carico di lavoro, i diritti di accesso e la sicurezza tecnica. Chiarire quali sono i fatti, le affermazioni e le supposizioni non confermate.

Utilizzare un nome solo quando l’identificazione è necessaria e proporzionata. Espressioni come “un account è stato in grado di eseguire l’azione” sono spesso più informative di “il dipendente X ha causato l’incidente”. Se opportuno, dare alle persone coinvolte l’opportunità di correggere le inesattezze fattuali o il contesto mancante.

La responsabilità individuale può essere necessaria in caso di condotta dannosa intenzionale, sabotaggio deliberato, inganno o trascuratezza grave e colposa di un rischio evidente. Anche allora, il giudizio deve scaturire dai fatti, dall’ascolto di entrambe le parti, da regole conoscibili e da una risposta proporzionata.

L’effetto di un’azione non è sufficiente per stabilire la colpevolezza. Un piccolo errore può causare accidentalmente gravi danni, mentre un comportamento imprudente a volte finisce senza danni. A Just Culture valuta quindi il comportamento e il contesto, non solo la fortuna o la sfortuna nel risultato.

Una cultura giusta ben applicata può aumentare la disponibilità a segnalare errori, rischi e quasi incidenti. Ciò consente a un’organizzazione di comprendere più rapidamente i segnali deboli, riconoscere modelli ricorrenti e concentrare le misure sulle cause piuttosto che solo sull’ultima persona nella catena.

Altri possibili vantaggi includono una maggiore fiducia, migliori conversazioni sulla sicurezza, supporto per dipendenti impegnati e miglioramento continuo dei processi. Questi effetti non derivano solo dall’etichetta. A recente revisione esplorativa di 36 interventi sanitari ha trovato tali risultati, ma sottolinea anche che è ancora difficile determinare esattamente quali componenti causano quale effetto. Just Culture è quindi un metodo di lavoro che supporta l’apprendimento, non una garanzia di meno incidenti.

Osserva la qualità e la distribuzione dei report, il tempo necessario per ottenere il feedback, la percentuale di misure di miglioramento completate, la ricorrenza di eventi simili e l’equità percepita della ricerca. I dipendenti devono sapere quali sono i confini e avere fiducia che casi simili verranno trattati in modo simile.

Un numero crescente di segnalazioni può inizialmente essere un buon segno: informazioni prima nascoste diventano visibili. Il semplice conteggio delle segnalazioni non è quindi sufficiente. Controlla anche se l’organizzazione impara da ciò, supporta i giornalisti, affronta le cause strutturali e motiva le decisioni in modo imitabile.

No. La Just Culture è stata fortemente sviluppata nel settore dell’aviazione e successivamente applicata, tra gli altri, nel settore sanitario, perché gli errori possono avere conseguenze importanti e la segnalazione tempestiva è vitale. L’essenza – essere in grado di riferire in modo sicuro, valutare il comportamento onestamente e nel contesto e migliorare il sistema – è utile anche nella sicurezza delle informazioni, nello sviluppo di software, nei servizi pubblici e in altre organizzazioni in cui le persone lavorano con sistemi complessi.

L’elaborazione deve adattarsi all’organizzazione. Una piccola fondazione ha ruoli, rischi e obblighi legali diversi rispetto a una compagnia aerea. Adottate quindi i principi, ma create voi stessi percorsi di segnalazione, poteri, limiti comportamentali e garanzie chiari. La recente analisi esplorativa di Just Culture in Healthcare mostra inoltre che gli interventi studiati variano e che le prove sull’implementazione di successo sono ancora limitate.

La sicurezza psicologica significa che le persone in una squadra osano correre rischi interpersonali: porre una domanda, esprimere dubbi, ammettere un errore o esprimere un’opinione diversa. Just Culture è più specifico su ciò che l’organizzazione fa con una segnalazione o un evento: come indaga, valuta il comportamento, protegge i giornalisti, distribuisce la responsabilità e implementa miglioramenti.

I concetti si rafforzano a vicenda, ma non sono la stessa cosa. Una squadra piacevole senza una valutazione chiara e coerente non è ancora Solo Cultura. Al contrario, un buon documento politico non funziona se le persone non osano parlare apertamente nella pratica. La ricerca sulla sicurezza psicologica menziona la leadership inclusiva, il sostegno e l’orientamento all’apprendimento come condizioni importanti. Consulta questa revisione sistematica.

I manager stabiliscono aspettative chiare, rispondono con calma alle cattive notizie e garantiscono che le segnalazioni siano indagate in modo indipendente e competente. Prima chiedono cosa è successo e quali circostanze hanno avuto un ruolo prima di trarre conclusioni sulle persone. Inoltre, liberano tempo, persone e budget per misure di miglioramento e forniscono feedback su ciò che è stato fatto con i report.

Anche le loro stesse azioni devono poter essere esaminate. Se ci si rivolge solo ai dipendenti esecutivi e le scelte relative al carico di lavoro, alle risorse o agli obiettivi poco chiari rimangono fuori dal quadro, la cultura non è giusta. La Guida AHRQ alle indagini sugli incidenti basate sul sistema enfatizza sia il supporto della leadership che l’individuazione dei fatti piuttosto che l’individuazione delle colpe.

I dipendenti segnalano errori rilevanti, quasi incidenti, condizioni non sicure e dubbi nel modo più tempestivo e concreto possibile. Partecipano alla ricerca, condividono anche informazioni che potrebbero risultare scomode e aiutano ad apportare miglioramenti utili per la pratica quotidiana. Si avvicinano ai colleghi con rispetto e chiedono aiuto quando la conoscenza, il tempo o le risorse sono insufficienti.

Just Culture non richiede perfezione o eroismo. Un dipendente rimane responsabile di agire con attenzione nell’ambito del suo ruolo, ma l’organizzazione rimane responsabile di un sistema funzionante, di una formazione adeguata e di condizioni realistiche. La responsabilità è quindi condivisa, non spostata.

In primo luogo, le persone e i sistemi sono protetti e la ricezione della segnalazione è confermata. Una persona autorizzata determina quindi chi gestirà la segnalazione, quali informazioni sono necessarie e quale riservatezza può essere garantita. La ricerca ricostruisce l’evento, coinvolge i soggetti coinvolti e guarda ai fattori tecnici, umani e organizzativi.

Successivamente vengono registrati i risultati e le misure, le persone coinvolte ricevono un feedback adeguato e viene monitorato se le misure sono state effettivamente implementate e funzionano. Una segnalazione senza un seguito visibile danneggia la fiducia. La ricerca sui sistemi di segnalazione degli incidenti avverte che la raccolta da sola non è sufficiente; sono proprio le azioni di miglioramento e un ciclo chiuso di apprendimento a determinarne il valore. Consulta questa revisione sistematica.

L’indagine inizia con una cronologia e fatti verificabili, non con un presunto colpevole. I ricercatori parlano con rispetto alle persone coinvolte, testano varie affermazioni ed esaminano procedure, formazione, strumenti, carico di lavoro, comunicazione, scelte progettuali e segnali precedenti. Viene registrato anche ciò che resta incerto.

Chiunque sia personalmente coinvolto o abbia un conflitto di interessi non dovrebbe decidere da solo l’esito. Le persone coinvolte devono essere in grado di spiegare i fatti rilevanti e di far correggere le inesattezze fattuali. La misura scelta deve essere adeguata al comportamento e alle circostanze e casi comparabili devono essere trattati in modo simile. Nel frattempo potrebbero essere necessarie misure di sicurezza urgenti, ma non dovrebbero essere presentate come una punizione dissimulata.

L’organizzazione determina in anticipo chi valuta il comportamento, secondo quali criteri e con quali possibilità di contraddizione o riconsiderazione. A seconda della gravità, possono essere coinvolti un manager, un responsabile della sicurezza, un responsabile delle risorse umane, un esperto in materia, una rappresentanza dei dipendenti o un comitato indipendente. Le questioni legali appartengono a qualcuno con competenze adeguate.

I valutatori non guardano solo al risultato, ma alla prevedibilità, all’intenzione, alla conoscenza, alla formazione, alle alternative disponibili e alle circostanze al momento dell’azione. Un risultato grave non dimostra di per sé un comportamento imprudente; un buon risultato non rende accettabile un comportamento consapevolmente pericoloso.

Non considerare il dubbio come una prova contro la persona interessata. Raccogli ulteriori fatti, chiedi a qualcuno esperto di esaminare le reali opzioni di azione e verifica se altri avrebbero potuto fare una scelta simile nelle stesse circostanze. Distinguere tra ciò che è visibile in seguito e ciò che la persona avrebbe potuto ragionevolmente sapere in quel momento.

Registrare il compromesso e l’incertezza rimanente. Una misura drastica del personale richiede un processo più rigoroso e indipendente, con un’udienza e un’opportunità di riconsiderazione. Inoltre, risolvi immediatamente i punti deboli del sistema; il disaccordo sulla responsabilità individuale non costituisce una ragione per l’esistenza di un problema di sicurezza dimostrabile.

La segnalazione riservata significa che l’identità è nota solo alle persone che ne hanno bisogno per un processo accurato. Segnalazione anonima significa che il destinatario non conosce l’identità. La riservatezza consente ulteriori domande e feedback personali; l’anonimato può abbassare la soglia se qualcuno teme ritorsioni o conflitti di interessi.

Offrire entrambi i percorsi, ove appropriato, e spiegare onestamente in anticipo cosa può e cosa non può essere protetto. L’anonimato completo non può sempre essere garantito né dal punto di vista tecnico né da quello legale e i dettagli di un evento possono indirettamente rendere qualcuno riconoscibile. Pertanto, non raccogliere più dati personali del necessario e limitare i periodi di accesso e conservazione. Le norme europee sull’aviazione menzionano la protezione e la rimozione dei dati identificativi come modi per sostenere la fiducia nei sistemi di segnalazione. Si veda la spiegazione EASA al Regolamento 376/2014.

Just Culture e la protezione degli informatori hanno un obiettivo correlato: le persone dovrebbero essere in grado di segnalare problemi gravi senza essere ingiustamente svantaggiate. Tuttavia, legalmente e praticamente non sono la stessa cosa. Un accordo interno sulla Just Culture non potrà mai sostituire i diritti legali, un canale di segnalazione esterno o la protezione contro le ritorsioni.

Assicurati che dipendenti, collaboratori esterni e volontari sappiano quale canale corrisponde a quale rapporto e dove possono ottenere consulenza indipendente. Non considerare una segnalazione come una questione di lealtà né tentare di bloccare contrattualmente un canale esterno legalmente consentito. La protezione precisa dipende dalla legge applicabile. La direttiva UE sulle segnalazioni di irregolarità comprende norme sui canali riservati, sul follow-up e sulla protezione contro le ritorsioni.

No. Restano in vigore gli obblighi di denuncia di incidenti, violazioni dei dati, sospetti di reati penali o altri eventi. Anche un supervisore, un giudice o un datore di lavoro autorizzato mantengono il loro ruolo legale. Just Culture non prevede che le informazioni debbano rimanere sempre segrete e non garantisce l’immunità.

Tuttavia, Just Culture richiede procedure chiare, proporzionate e coerenti: separare, ove possibile, l’apprendimento dal processo decisionale disciplinare, limitare l’accesso alle informazioni di reporting e spiegare quando la segnalazione può essere obbligatoria. Adattare l’approccio al diritto del lavoro, alla normativa sulla privacy, alle norme sulla denuncia delle irregolarità, alle norme di settore e alla partecipazione esistente dei dipendenti. In caso di dubbio, far valutare legalmente la situazione specifica.

Per prima cosa delineare il modo in cui le persone segnalano adesso, dove c’è paura o incertezza e come sono stati trattati i casi precedenti. Quindi elaborare semplici regole insieme ai dipendenti e ai rappresentanti competenti: cosa segnalare, attraverso quale canale, chi vede le informazioni, come si svolge l’indagine, dov’è il limite comportamentale e come si può far riconsiderare una decisione.

Formare manager e ricercatori con esempi realistici. Esercitati nel processo, gestisci i primi report in modo visibile e attento e pubblica punti di apprendimento e progressi in forma anonima. Misurare la fiducia, monitorare e adattare il processo. Meglio iniziare in piccolo e completo che con un programma vasto e senza capacità. L’EASA consiglia alle organizzazioni di includere chiari processi di Just Culture nelle loro politiche di sicurezza e di coinvolgere i rappresentanti dei dipendenti. Consultare la Guida EASA per i sistemi di segnalazione.

Gli errori comuni includono: equiparare la Cultura Giusta al non parlare mai, stabilire dei limiti solo dopo un incidente, confondere la gravità del risultato con la colpevolezza del comportamento, esaminare solo l’ultima azione umana e trattare casi simili in modo diverso. Anche la grande diffusione di nomi, la fuga di informazioni e un manager che è allo stesso tempo direttamente coinvolto, ricercatore e decisore danneggiano la fiducia.

Un’altra trappola è chiedere segnalazioni ma non fornire feedback o miglioramenti. Il reporter si assume quindi il rischio mentre l’organizzazione non mantiene la promessa di apprendimento. Il rimedio è verificabile: ruoli chiari, protezione delle informazioni, feedback tempestivo, azioni di miglioramento visibili e test periodici di coerenza.

Una Cultura Giusta orientata alla ripresa non guarda solo alle regole, alle cause e alla prevenzione futura, ma anche al danno che le persone e le relazioni hanno subito a seguito di un evento e alla risposta ad esso. Le domande includono: chi è stato colpito, di cosa ha bisogno, chi ha il dovere di ripristinare qualcosa e come si può ricostruire la fiducia in modo responsabile?

Ciò può portare al riconoscimento, alla spiegazione, all’aiuto pratico, al ripristino dei contratti di lavoro o ad una conversazione guidata. La partecipazione deve essere attenta e appropriata; Il recupero non deve diventare uno strumento di pressione per imporre il perdono, il silenzio o la rinuncia ai diritti. La letteratura scientifica sulla Just Culture riparativa è in crescita, ma la revisione di scoping del 2026 conclude che le prove sugli interventi e sull’implementazione di successo sono ancora limitate.

Chiedere separatamente di cosa hanno bisogno i diretti interessati, i giornalisti e le altre parti coinvolte. Pensate a informazioni concrete, una persona di contatto permanente, riposo o compiti adattati, supporto tra pari e accesso all’aiuto professionale. Spiegare cosa può e non può fare la ricerca e quando verrà fornito il feedback. Evita la speculazione e proteggi i dati personali.

Il sostegno non è un giudizio di colpa e non dovrebbe dipendere dal comportamento successivo. Allo stesso tempo, potrebbe essere necessaria una misura di sicurezza temporanea, ad esempio una supervisione aggiuntiva o un altro compito. Giustificare tale misura, limitarla allo stretto necessario e rivalutarla non appena si conosceranno più fatti.

In caso di incidente mancato, qualcosa è andato storto o si è verificato un pericolo, ma il danno grave non è stato causato dal caso, da un intervento tempestivo o da un ulteriore livello di sicurezza. È allora che un’organizzazione può imparare senza che nessuno debba prima sopportarne tutte le conseguenze. Anche deviazioni ricorrenti, istruzioni poco chiare e piccole deviazioni possono essere segnali precoci di un problema di sistema.

Non chiedetevi quindi solo “cosa è andato storto?”, ma anche “cosa lo ha fatto andare bene?” e “quale barriera ha funzionato?”. Semplifica la creazione di report e fornisci feedback. Una revisione sistematica dei quasi incidenti nel settore sanitario ha rilevato che il supporto della leadership, semplici percorsi di segnalazione, la conoscenza e una risposta non punitiva influenzano il comportamento di segnalazione. Vedi la recensione su PubMed.

Non limitare Just Culture ai dipendenti con contratto a tempo indeterminato. Fornitori, appaltatori, ricercatori, stagisti e volontari possono essere i primi a notare una vulnerabilità, un errore o una situazione non sicura. Fornire loro un percorso di segnalazione comprensibile, spiegare quale protezione si applica e chiarire negli accordi chi indagherà e fornirà feedback.

L’organizzazione non può controllare unilateralmente tutto il diritto del lavoro o le conseguenze contrattuali di un’altra parte. Concordare pertanto preventivamente come verranno protette le informazioni, quando verranno condivise e come si eviteranno ritorsioni o conflitti di interessi. Oltre ai dipendenti, le norme aeronautiche europee fanno riferimento anche al personale assunto; le norme dell’UE in materia di denuncia delle irregolarità possono includere, nel loro ambito di applicazione, anche volontari, lavoratori autonomi e appaltatori.

No. La sovranità non è autarchia e non richiede la completa indipendenza. Le organizzazioni e gli Stati dipendono sempre dalla conoscenza, dai fornitori, dalle materie prime e dalla cooperazione.

L’obiettivo è che le dipendenze siano visibili, gestibili e sostituibili dove necessario. È possibile esternalizzare il lavoro e mantenere comunque il controllo, purché le responsabilità, i diritti, l’accesso, la continuità e le opzioni di uscita siano adeguatamente organizzati.

No. Nessun prodotto può garantire da solo la sovranità digitale. La sovranità nasce dalla combinazione di governance, contratti, giurisdizione, architettura, apertura, conoscenza, gestione e alternative fattibili.

OpenKAT e OciDeck possono fornire elementi concreti: maggiore comprensione, verificabilità, formati aperti, autogestione e meno dipendenze inutili. L’organizzazione deve progettare consapevolmente e continuare a testare queste opzioni.

Registrare una misurazione di base e un livello desiderato per ciascun sistema critico. Quindi misurare le proprietà concrete, come la quota di parti della catena conosciute, l’esportazione di dati testata, le chiavi gestite dal cliente, il ripristino senza fornitori, le interfacce aperte e il tempo necessario per il passaggio.

Segnalare anche le dipendenze rimanenti e i rischi accettati. Il progresso non significa che ogni dipendenza scompare, ma che l’organizzazione acquisisce maggiore consapevolezza, libertà di scelta e spazio di azione dimostrabile.

Presentare richieste prima della conclusione del contratto. Chiedi informazioni su giurisdizione, proprietà, ubicazione dei dati, subappaltatori, gestione remota, gestione delle chiavi, standard aperti, formati di esportazione, diritti di audit, continuità e risoluzione.

Registrare inoltre come vengono fornite le prove e come vengono segnalate le modifiche. Un marchio di qualità o un’affermazione di marketing generale non sostituisce un accordo verificabile. Utilizzare gli obiettivi ECSF e i livelli SEAL come linguaggio comune, ove appropriato.

No. L’archiviazione europea dei dati è rilevante, ma non dice tutto su giurisdizione, proprietà, gestione, accesso alle chiavi, subappaltatori e dipendenza tecnica.

Valutare quindi l’intera struttura: quali soggetti forniscono il servizio, quali diritti possono essere invocati, chi può eseguire azioni di gestione, chi gestisce le chiavi di crittografia e quali opzioni di uscita sono disponibili?

SÌ. La dipendenza può influenzare la disponibilità, l’integrità e la riservatezza delle informazioni. Considera il fallimento o la cessazione di un servizio, l’accesso indesiderato in un sistema legale diverso o i cambiamenti che l’organizzazione non può controllare da sola.

Ecco perché la sovranità appartiene alla regolamentazione, all’organizzazione e alla tecnologia: le tre parti interconnesse descritte nel libro come ROT. Non è una questione politica separata oltre alla sicurezza delle informazioni.

Non quando i requisiti mirano a rischi gestibili e si applicano in modo uguale e verificabile a tutti i fornitori. Il protezionismo protegge innanzitutto la propria industria; la politica di sovranità protegge il controllo, la continuità, l’integrità e la riservatezza.

La sola nazionalità è quindi un criterio debole. La giurisdizione, gli accordi applicabili, l’isolamento tecnico, l’apertura e le opzioni di uscita sono più sostanziali.

No. Un nome o una località europea non è una garanzia completa. Un fornitore europeo può anche essere rilevato, fallire, fare molto affidamento su tecnologia non europea o fornire scarse garanzie contrattuali.

Considera le caratteristiche strutturali controllabili: proprietà e controllo, legge applicabile, gestione e accesso alle chiavi, dipendenze della catena, standard aperti e un piano di uscita eseguibile.

No. L’open source fornisce importanti diritti per studiare il software, modificarlo e farlo mantenere da altri. Può quindi sostenere la trasparenza, la sostituibilità e lo sviluppo della conoscenza.

Ma questi diritti hanno valore pratico solo se c’è documentazione, persone, gestione, finanziamenti, aggiornamenti sicuri e accesso ai propri dati. L’open source può anche dipendere da un unico manutentore, da un servizio cloud chiuso o da un’infrastruttura difficile da sostituire.

No. La sovranità dipende dal contesto. Il livello desiderato dipende dalla criticità del processo, dalla sensibilità dei dati, dai requisiti legali, dalla propensione al rischio e dalle alternative disponibili.

Il livello più alto per tutti i sistemi potrebbe essere inutilmente costoso o irrealizzabile. Una scelta motivata per sistema è più forte di un obiettivo generale senza priorità.

Non necessario. I requisiti di interoperabilità, trasparenza, sicurezza e sostituibilità possono effettivamente stimolare l’innovazione perché i nuovi fornitori possono connettersi più facilmente e i clienti diventano meno vincolati.

Esistono veri e propri compromessi in termini di costi, velocità e funzionalità. Questi devono essere resi espliciti. Il contrasto tra “innovazione o sovranità” è troppo semplice; si tratta di innovazione responsabile all’interno di un profilo di rischio prescelto.

Inizia con l’intuizione. Creare una panoramica di processi critici, dati, sistemi, fornitori, subappaltatori, accesso alla gestione, giurisdizione applicabile e opzioni di uscita esistenti.

Quindi collega le dipendenze più importanti alla disponibilità, all’integrità e alla riservatezza. Solo quando è chiaro cosa è fondamentale e da cosa dipende, è possibile scegliere un obiettivo e misure adeguate.

Il libro Sovranità! Come? discute lo sviluppo storico, il rapporto con la sicurezza informatica, la ECSF, gli argomenti del dibattito e un percorso pratico di crescita per le organizzazioni.

Il messaggio centrale è concreto: la sovranità non è un concetto tutto o niente e non è un progetto una tantum. È l’organizzazione permanente dell’intuizione, della direzione e dello spazio per l’azione.

Il concetto prese forma in Europa nel tardo Medioevo e nella prima età moderna. Nel XVI secolo Jean Bodin descrisse un potere statale supremo e permanente. La pace di Westfalia del 1648 legò poi fortemente la sovranità agli stati territoriali e al principio di non ingerenza.

Successivamente, la legittimità è passata dai monarchi ai popoli e gli stati hanno iniziato a esercitare i poteri congiuntamente, ad esempio all’interno dell’Unione europea. La storia mostra che la sovranità ruota sempre attorno alla stessa domanda fondamentale: chi ha, in ultima analisi, l’ultima parola?

Perché la sovranità non riguarda solo la probabilità, ma anche l’impatto e la capacità di agire. Un evento può essere improbabile e tuttavia avere conseguenze inaccettabili per un processo critico.

Del resto, la dipendenza può già incidere senza però bloccarne effettivamente l’accesso. La possibilità di sanzioni, ordinanze giuridiche o rescissione può modificare lo spazio decisionale e negoziale.

I governi, le aziende e le organizzazioni sociali sono diventati fortemente dipendenti da un numero limitato di fornitori per cloud, software per ufficio, comunicazioni e intelligenza artificiale. Allo stesso tempo, la proprietà, la legislazione, le sanzioni, le acquisizioni e le relazioni geopolitiche possono cambiare.

Di conseguenza, il controllo formale può entrare in conflitto con la dipendenza effettiva. La questione urgente non è solo se un fornitore sia affidabile oggi, ma se l’organizzazione possa ancora agire domani se cambiano le regole, l’accesso o gli interessi.

Distinguere tra funzioni veramente indispensabili e dipendenze nate per abitudine, conoscenze mancate o vecchie scelte. Mappare concretamente connessioni, formati di dati, licenze, processi e competenze.

Quindi pratica l’esportazione, la ripresa e le alternative prima che ci sia una crisi. Un piano di uscita che non è mai stato testato offre poche certezze. A volte la migrazione completa non è immediatamente fattibile, ma formati aperti, architettura modulare e un secondo percorso di implementazione possono già migliorare la situazione.

Allora un approccio graduale è saggio. Determinare innanzitutto per quali processi la dipendenza rappresenta il rischio maggiore e quali funzioni sono realmente necessarie. Quindi migliorare i contratti, l’architettura e la portabilità e migrare dove è disponibile un’alternativa adeguata.

Il fatto che un’alternativa sia oggi meno matura è un argomento sul ritmo e sull’esecuzione, non automaticamente un motivo per ignorare il rischio. Il libro quindi discute un percorso di crescita invece di una grande transizione.

La sovranità digitale è la misura in cui un governo o un’organizzazione mantiene effettivamente il controllo sulle proprie funzioni, dati e dipendenze digitali. Contano i diritti formali e le opzioni effettive per l’azione.

Domande specifiche sono: dove si trovano i dati, chi può accedervi, quale legge si applica, chi gestisce le chiavi, il servizio può continuare in caso di conflitto ed è realisticamente possibile il passaggio?

L’ECSF è un quadro di valutazione europeo per la sovranità del cloud. Aiuta le organizzazioni pubbliche a descrivere i rischi legati alla sovranità, a stabilire i requisiti per gli acquisti e a confrontare la situazione attuale e quella auspicata.

Il quadro sposta la conversazione da affermazioni generali, come “europeo” o “sovrano”, a proprietà verificabili. Esamina, tra le altre cose, giurisdizione, dati, operazioni, catene, tecnologia, sicurezza e sostenibilità.

La sovranità riguarda autorità e direzione: chi ha l’ultima parola e chi ha la responsabilità? L’autonomia riguarda la capacità pratica di agire in modo indipendente e di utilizzare alternative.

Un’organizzazione può essere formalmente autorizzata ma avere poca autonomia se non può tecnicamente cambiare o se solo un fornitore può gestire il sistema. La sovranità senza sufficiente spazio d’azione rimane quindi in gran parte sulla carta.

La sovranità è l’autorità di prendere decisioni vincolanti e di assumersene la responsabilità. Negli ambienti digitali, la questione principale è chi decide in ultima analisi su dati, infrastrutture, tecnologia e accesso.

Ciò non significa che un’organizzazione debba costruire o gestire tutto da sola. Tuttavia, deve essere in grado di fare scelte consapevoli, far rispettare gli accordi e agire quando le circostanze cambiano. Il libro Sovranità! Come? Si tratta di una questione amministrativa pratica.

I livelli SEAL descrivono livelli crescenti di sovranità del cloud. Il livello 0 è un cloud pubblico standard senza misure di sovranità aggiuntive; Il livello 4 rappresenta un ambiente altamente sovrano con autonomia dimostrabile.

I livelli non rappresentano un voto per un fornitore. Aiutano un’organizzazione a determinare un livello attuale (IST) e un livello desiderato (SOLL) appropriati per ogni applicazione. A un sistema critico può quindi essere assegnato uno scopo più elevato rispetto a un servizio pubblico o facilmente sostituibile.

L’open source può aiutare perché un’organizzazione può studiare il software, farlo controllare, adattare e mantenere da un’altra parte. I diritti aperti sostengono quindi la trasparenza, la sostituibilità e lo sviluppo della propria conoscenza.

L’open source non è una garanzia automatica di sovranità. Il valore pratico dipende anche dalla documentazione, dalle persone, dalla gestione, dai finanziamenti, dagli aggiornamenti sicuri, dai formati di dati aperti e dall’infrastruttura su cui viene eseguito il software.

La ECSF distingue otto obiettivi correlati: sovranità strategica; sovranità giuridica e giurisdizionale; sovranità dei dati e dell’intelligenza artificiale; sovranità operativa; sovranità a catena; sovranità tecnologica; sovranità in materia di sicurezza e conformità; e sovranità in termini di sostenibilità.

Questa classificazione impedisce che una caratteristica, come l’ubicazione di un data center, venga erroneamente utilizzata come prova della piena sovranità. Un servizio può segnare forte in un obiettivo e debole in un altro.

OciDeck supporta la sovranità delle informazioni e della tecnologia consentendo ai contenuti della presentazione di rimanere in formato Markdown leggibile. I formati aperti rendono il contenuto più controllabile, riutilizzabile e portabile rispetto a quando è contenuto esclusivamente in un formato applicativo chiuso.

L’elaborazione locale, l’esportazione HTML offline e le funzionalità di condivisione e privacy mirate possono ridurre la dipendenza dai servizi di presentazione di terze parti e la distribuzione accidentale. La sovranità ultima dipende anche dallo stoccaggio, dalla gestione e dalle scelte degli utenti. Ulteriori informazioni su OciDeck.

OpenKAT aiuta principalmente con la sovranità operativa, tecnologica e di sicurezza. Riunisce oggetti digitali, relazioni, osservazioni e risultati in modo che un’organizzazione possa comprendere e monitorare meglio il proprio ambiente e i propri rischi.

Poiché OpenKAT è open source e può essere eseguito da solo, un’organizzazione può monitorarne il funzionamento e scegliere chi gestisce il sistema. OpenKAT non garantisce la sovranità completa: restano necessari un’attenta gestione, ambito, protezione dei dati, conoscenza e follow-up. Ulteriori informazioni su OpenKAT.

Un approccio utile è: 1. processi di inventario, dati e dipendenze; 2. determinare il livello desiderato di sovranità per sistema; 3. migliorare gli acquisti, i contratti, l’architettura, la conoscenza e le alternative; 4. Controllare periodicamente se le misure funzionano ancora e apportare modifiche.

Trattatelo come un ciclo. Fornitori, proprietà, legislazione e cambiamento tecnologico. Una valutazione una tantum diventa quindi rapidamente obsoleta.

Il consiglio è in ultima analisi responsabile della direzione, della propensione al rischio e dell’accettazione del rischio residuo. Gli acquisti, gli affari legali, la sicurezza delle informazioni, l’architettura, la privacy, la gestione e il titolare del processo forniscono ciascuno una parte necessaria del quadro.

Poiché le scelte spesso hanno conseguenze di lunga durata, il libro chiama la sovranità “chefsache”. L’argomento non può limitarsi esclusivamente alla tecnologia o alla gestione dei contratti.

L’open source è una forma di licenza. Il creatore o il titolare dei diritti dà ad altri il permesso in anticipo di utilizzare, studiare, copiare, distribuire e adattare l’opera.

Il diritto di apportare modifiche è essenziale. Se la modifica non è consentita, non è open source.

Il nocciolo della questione è legale. L’open source riguarda il modo in cui viene esercitato il diritto d’autore: tramite una licenza che concede ampi diritti di utilizzo.

Potrebbero esserci idee tecniche e sociali dietro, ma senza una licenza adeguata qualcosa non è open source.

Significa che il titolare dei diritti dà il permesso di utilizzare, studiare, copiare, distribuire e modificare il codice sorgente attraverso una licenza open source.

Il software rimane protetto dal diritto d’autore. La licenza determina quali diritti e condizioni si applicano.

L’open source e il software libero riguardano i diritti: utilizzare, studiare, condividere e adattare. Freeware di solito significa semplicemente che qualcosa è gratuito da usare.

Dominio pubblico significa che non esiste più alcuna restrizione sul copyright o che il titolare dei diritti vi ha rinunciato nella misura legalmente possibile. Questo è diverso dall’open source.

No. L’open source garantisce molti diritti, ma sempre entro i termini della licenza.

Tali condizioni possono riguardare, ad esempio, l’attribuzione, la conservazione dei testi di licenza o la condivisione di modifiche nell’ambito della stessa licenza.

Il creatore o il titolare dei diritti rimane il proprietario del diritto d’autore, a meno che tale diritto non sia stato trasferito.

Open source non significa che non esiste un proprietario. Significa che il proprietario concede ampi diritti ad altri attraverso una licenza.

SÌ. L’open source non esclude l’uso commerciale. Un’azienda può utilizzare l’open source, vendere servizi open source o offrire essa stessa software open source.

Il modello di prezzi e ricavi sono separati dai diritti open source.

L’open source riguarda i diritti su un’opera, solitamente software. Gli standard aperti riguardano accordi, specifiche o protocolli che possono essere utilizzati da più parti.

Possono rafforzarsi a vicenda, ma sono cose diverse.

Una licenza open source è un’autorizzazione preventiva concessa dal titolare dei diritti. Indica cosa possono fare gli altri con il lavoro e quali condizioni si applicano.

Senza tale licenza, il normale diritto d’autore continua ad applicarsi e il riutilizzo solitamente non è consentito.

Perché il copyright nasce automaticamente. In linea di principio, chiunque crei un testo, un disegno o un software ne detiene i diritti.

Una licenza chiarisce quale autorizzazione ricevono gli altri. Con l’open source, questa autorizzazione è ampia e concordata in anticipo.

Il codice è quindi visibile, ma non automaticamente gratuito da utilizzare. La visibilità non è consenso.

Senza una licenza, un’altra persona generalmente non può copiare, distribuire o modificare il codice, salvo limitate eccezioni legali.

Le licenze permissive offrono molta libertà e solitamente impongono condizioni limitate, come l’attribuzione e la conservazione del testo della licenza.

Anche le licenze copyleft garantiscono ampi diritti, ma possono richiedere la distribuzione di opere derivate con la stessa licenza o con una simile.

Il copyleft è un principio di licenza in cui la libertà deve essere trasmessa. Chi distribuisce l’opera, spesso in forma adattata, deve riconoscere ad altri gli stessi diritti.

Non si tratta quindi di una rinuncia ai diritti, ma piuttosto di un modo attivo di utilizzare i diritti per mantenere l’apertura.

Dipende dalla licenza e da cosa fai. Alcune licenze copyleft potrebbero richiedere la divulgazione se si distribuisce software modificato.

Solo l’uso interno di solito non comporta automaticamente tale obbligo, ma l’esito preciso dipende dalla situazione e dalla licenza.

Sì, molte licenze open source consentono l’uso commerciale. Questa è proprio una caratteristica dell’open source.

Tuttavia, è necessario rispettare le condizioni di licenza. Valuta la possibilità di menzionare il tuo nome, i testi della licenza o le condizioni per la distribuzione.

Sì, l’open source dovrebbe consentire la personalizzazione. È anche possibile la vendita, purché vengano rispettate le condizioni di licenza.

Alcune licenze richiedono che tu fornisca o renda disponibile il codice sorgente modificato quando distribuisci l’opera modificata.

Questi sono modi per mantenere visibili il creatore originale e la licenza. Attribuzione di solito significa attribuzione. Un file di avviso contiene avvisi legali. L’intestazione della licenza si trova spesso all’inizio di un file.

Questi obblighi garantiscono che i diritti e l’origine rimangano riconoscibili.

Una clausola sui brevetti garantisce che gli utenti ricevano anche il permesso per i brevetti rilevanti dai contributori a determinate condizioni.

Questo può essere importante perché il software può essere interessato non solo dal diritto d’autore, ma talvolta anche dai diritti di brevetto.

Il rischio principale è che le condizioni di licenza non vengano rispettate. Quindi potresti utilizzare l’opera senza un permesso valido.

Ciò può comportare obblighi di riparazione, rivendicazioni legali, danni alla reputazione o problemi con le vendite, le gare d’appalto o la revisione.

La conformità open source significa che un’organizzazione sa quale open source utilizza, quali licenze ne derivano e quali obblighi si applicano.

Si tratta principalmente di normale gestione giuridica e organizzativa: registrare, verificare, conformarsi e poter spiegare cosa è stato utilizzato.

No, non a causa della natura open source. La sicurezza dipende dalla progettazione, manutenzione, controllo, utilizzo e monitoraggio delle vulnerabilità.

L’apertura consente il controllo, ma non è una garanzia automatica di sicurezza.

No. Spesso tutti possono avanzare proposte, ma ciò non significa che tutti possano semplicemente apportare modifiche.

Per i progetti seri, gli amministratori valutano quali contributi includere. L’affidabilità dipende dalla governance e dalla manutenzione, non solo dal tipo di licenza.

No. Il supporto può essere volontario, guidato dalla comunità o commerciale. Molte aziende forniscono supporto a pagamento per l’open source.

La licenza determina i diritti sull’opera; il supporto è un servizio separato.

No. L’open source riguarda i diritti di utilizzo, non il prezzo.

Un prodotto open source può essere scaricato gratuitamente, ma il supporto, l’hosting, la certificazione, la formazione o la personalizzazione possono essere a pagamento.

No. La gratuità riguarda il prezzo. La libertà riguarda i diritti.

Un prodotto gratuito può essere rigorosamente chiuso. Un prodotto open source dà i diritti di utilizzo, studio, condivisione e modifica.

No. L’open source può essere creato da volontari, ma anche da aziende, governi, università e fondazioni.

La licenza non dice nulla sulla professionalità. È necessario valutarlo in base alla qualità, alla gestione e al contesto.

No. L’open source può essere molto professionale e il software commerciale può essere scarsamente gestito. È possibile anche il contrario.

La professionalità è evidente dalla manutenzione, dalla documentazione, dalla governance, dalla qualità e dagli accordi, non solo dalle licenze aperte o chiuse.

Apertura significa che tutti possono guardare, compresi i malintenzionati. Ma ciò significa anche che è possibile il controllo da parte di utenti, ricercatori e fornitori.

La sicurezza non deriva solo dalla segretezza. Richiede manutenzione, risposta e uso attento.

No. I diritti legali riguardano tutti: utenti, amministratori, acquirenti, avvocati, revisori dei conti e responsabili politici.

Gli sviluppatori spesso lavorano con il codice, ma anche le organizzazioni traggono vantaggio dalla trasparenza, dalla libertà di scelta e dalla verificabilità.

Potrebbe essere un compromesso, ma non è automaticamente uno svantaggio. L’open source significa determinare consapevolmente quali parti si desidera condividere e in quali condizioni.

A volte la condivisione aperta è strategicamente utile, ad esempio per promuovere la collaborazione, la fiducia o la standardizzazione.

Ciò varia in base al progetto. Il controllo può provenire da manutentori, utenti, ricercatori di sicurezza, audit, scansioni automatiche e organizzazioni che distribuiscono il software.

L’open source rende possibile tale controllo, ma non lo organizza da solo.

Dipende dalla situazione. Gli amministratori del progetto possono creare un aggiornamento, ma anche l’utente o l’organizzazione devono applicare tale aggiornamento.

L’open source non cambia il fatto che chiunque utilizzi un software rimane responsabile di un’attenta gestione.

Ciò varia notevolmente. I progetti attivi possono rispondere rapidamente; non abbandonare i progetti. Lo stesso vale anche per il software chiuso.

Pertanto, non guardare solo alla licenza, ma anche alla manutenzione, al processo di reporting e alle pratiche di rilascio.

I rischi della catena di fornitura sorgono quando si dipende da parti di terzi. Se una parte di questo tipo è vulnerabile, dannosa o sottoposta a scarsa manutenzione, ciò può avere conseguenze sul tuo prodotto.

Questo rischio non è esclusivo dell’open source, ma l’open source spesso rende le dipendenze più visibili.

Le dipendenze sono parti su cui si basa un prodotto. Con il software, si tratta spesso di librerie o pacchetti di altri.

Sono importanti perché i diritti, le vulnerabilità e la manutenzione di quelle parti influenzano anche il tuo utilizzo.

Guarda la licenza, la manutenzione, la documentazione, come vengono esaminate le modifiche e come vengono gestiti gli avvisi di sicurezza.

L’affidabilità è una combinazione di chiarezza giuridica, qualità e gestione.

I segnali positivi sono informazioni chiare sulle licenze, aggiornamenti recenti, documentazione comprensibile, un processo di reporting attivo e un processo decisionale visibile.

È utile anche che più persone o organizzazioni contribuiscano, in modo che il progetto non dipenda completamente da una persona.

Cerca vecchie versioni, notifiche senza risposta, informazioni sulla licenza mancanti, manutentori poco chiari o nessuna risposta ai problemi di sicurezza.

Questi sono i rischi del progetto. Si verificano sia nel software aperto che in quello chiuso, ma nell’open source sono spesso più visibili.

Durante un audit di sicurezza, qualcuno valuta specificamente se esistono vulnerabilità o punti deboli. Con l’open source, il codice sorgente può essere esaminato direttamente.

Un audit è un’istantanea. La manutenzione e il follow-up continueranno quindi a essere necessari.

Una SBOM è una distinta base del software: una panoramica dei componenti software utilizzati.

Una tale panoramica aiuta a gestire licenze, vulnerabilità e dipendenze. È particolarmente utile per le organizzazioni che devono essere in grado di spiegare cosa stanno utilizzando.

Un progetto open source viene creato quando un titolare dei diritti pubblica un’opera con una licenza open source. Ciò spesso include documentazione, un luogo per i contributi e un modo per prendere decisioni.

La licenza è la base giuridica; la comunità e il metodo di lavoro determinano il modo in cui il progetto continua a crescere.

Questo di solito viene fatto dai manutentori o dagli amministratori del progetto. Valutano se un contributo è in linea con la qualità, la direzione e gli accordi del progetto.

Open source non significa che ogni modifica diventa automaticamente parte del progetto ufficiale.

Un manutentore è qualcuno che gestisce un progetto. Quella persona o gruppo esamina i contributi, rilascia comunicati, monitora la direzione e mantiene la documentazione o i processi.

Nell’open source, questo ruolo è importante perché i diritti sono ampi, ma la collaborazione richiede comunque organizzazione.

Un collaboratore è qualcuno che contribuisce a un progetto. Potrebbe trattarsi di codice, ma anche di documentazione, traduzione, test, progettazione, spiegazione o segnalazione di problemi.

I contributi open source sono quindi più ampi della programmazione.

Un fork è la tua copia di un progetto su cui qualcuno può continuare a lavorare in modo indipendente. Ciò è possibile perché l’open source consente la modifica e la distribuzione.

A volte un miglioramento si riflette successivamente nel progetto originale. A volte una biforcazione cresce nella sua stessa direzione.

Si tratta di una proposta per includere una modifica in un progetto. L’amministratore può rivedere, discutere, modificare o rifiutare la modifica.

È un modo pratico per organizzare la collaborazione attorno all’open source.

La governance comunitaria riguarda gli accordi con i quali un progetto prende decisioni. Considerare chi può partecipare al processo decisionale, come vengono risolti i conflitti e come vengono nominati i nuovi amministratori.

La licenza dà diritti; la governance regola la cooperazione.

Nei progetti guidati dalla comunità, il controllo spetta principalmente a una comunità di partecipanti. Nei progetti guidati dall’azienda, l’azienda ha spesso un ruolo importante o decisivo.

Entrambe le forme possono funzionare bene, purché sia ​​chiaro chi decide e a quali condizioni.

Dipende dalla governance. Alcuni progetti hanno regole decisionali, codici di condotta o fondamenti chiari. Altri progetti sono più informali.

I buoni accordi sono importanti perché i diritti aperti non significano automaticamente che tutti siano d’accordo.

I progetti si fermano quando i manutentori esauriscono il tempo, i fondi mancano, la necessità scompare o emerge una soluzione migliore.

Questo non è esclusivo dell’open source. La differenza è che con l’open source gli altri a volte possono continuare con un fork.

Le aziende non traggono necessariamente profitto dalla vendita esclusiva del codice, ma dai servizi che lo circondano. Prendi in considerazione hosting, supporto, implementazione, gestione, formazione, certificazione o personalizzazione.

La licenza aperta e il modello di business sono due livelli diversi.

I modelli comuni includono supporto a pagamento, hosting gestito, consulenza, certificazione, formazione, doppia licenza e open core.

Il punto di partenza è spesso: i diritti fondamentali sono aperti, ma la comodità, la sicurezza o i servizi aggiuntivi possono essere pagati.

Open core significa che il nucleo di un prodotto è open source, mentre alcune funzionalità aggiuntive sono chiuse o a pagamento.

Può funzionare, ma richiede una comunicazione chiara. Gli utenti devono sapere quale parte è aperta e quale no.

La doppia licenza significa che la stessa opera è disponibile con due licenze diverse. Ad esempio, una licenza open source e una licenza commerciale.

Ciò può dare alle organizzazioni una scelta, ma è possibile solo se il titolare dei diritti ha il diritto di offrire entrambe le licenze.

Hosting gestito o SaaS significa che qualcuno offre software open source come servizio. L’utente non dovrà quindi installare e gestire il software da solo.

Il software può essere open source, mentre il servizio che lo circonda è a pagamento.

Le aziende possono farlo per aumentare la fiducia, stimolare la collaborazione, stabilire uno standard o accelerare l’adozione.

L’open source può anche aiutare a ridurre la dipendenza da un unico fornitore e costruire un ecosistema.

Perché ad altri è consentito basarsi sul lavoro esistente. Non devono ricominciare da capo e possono condividere miglioramenti.

La licenza rende tale collaborazione legalmente possibile.

L’open source può ridurre la dipendenza da un fornitore perché gli utenti hanno il diritto di studiare il software, modificarlo e gestirlo altrove.

Ciò non significa che il passaggio sia sempre facile, ma che la base giuridica è meno chiusa.

L’open source è interessante quando sono importanti la collaborazione, la trasparenza, la verificabilità, il riutilizzo o l’indipendenza.

È particolarmente forte nelle infrastrutture condivise, nei valori pubblici e nelle situazioni in cui la fiducia richiede più di una promessa da parte del fornitore.

L’open source è meno adatto quando il titolare dei diritti vuole limitare la distribuzione, l’accesso o la modifica. Questa è una scelta strategica riguardo al controllo.

È anche meno appropriato se un’organizzazione desidera concedere diritti senza essere disposta a registrare chiaramente le condizioni di licenza e la gestione.

Le startup possono basarsi più rapidamente sui componenti esistenti e acquisire più facilmente la fiducia attraverso l’apertura. Possono anche sviluppare una comunità o un mercato attorno a un progetto aperto.

Devono essere consapevoli delle licenze, del posizionamento e del loro modello di entrate.

Per i governi, l’open source può contribuire alla trasparenza, alla verificabilità, al riutilizzo e alla minore dipendenza da un unico fornitore.

Ciò si adatta bene alla responsabilità pubblica, a condizione che la gestione, la sicurezza e la conformità legale siano adeguatamente organizzate.

L’istruzione può utilizzare l’open source per imparare da esempi reali, condividere materiali e consentire agli studenti di contribuire a progetti esistenti.

Poiché l’adattamento è consentito, i materiali didattici o il software possono essere meglio allineati con la pratica educativa.

L’open source può aiutare perché le organizzazioni non dipendono completamente dalla conoscenza chiusa o da un unico fornitore. Possono far controllare come funziona qualcosa e farlo aggiustare.

La sovranità richiede qualcosa di più del semplice open source, ma i diritti aperti sono un elemento importante.

L’open source rende visibile in quali condizioni un’opera può essere utilizzata e, nel caso del software, come si presenta il codice sorgente.

Ciò facilita il controllo e la spiegazione. Transparency only really arises when documentation and governance are also clear.

Poiché ad altri è consentito utilizzare e adattare il lavoro esistente, non tutti devono ricreare la stessa cosa.

Ciò può ridurre gli sprechi e condividere la manutenzione, soprattutto quando più parti hanno lo stesso problema.

L’open source mostra come funziona un’organizzazione, quale qualità aspira e cosa rappresenta. Le persone possono facilmente contribuire o venire a conoscenza di ciò che sta accadendo.

Questo può essere interessante per i professionisti che apprezzano l’apertura e l’artigianalità.

I concorrenti possono collaborare su parti di cui tutti hanno bisogno, senza che tali parti debbano essere il prodotto distintivo.

La licenza fornisce chiarezza in anticipo sui diritti, in modo che la collaborazione dipenda meno da accordi separati.

Le infrastrutture pubbliche richiedono fiducia, continuità e verificabilità. L’open source può aiutare perché la base non è completamente a porte chiuse.

Ciò rende più possibile il controllo indipendente e la manutenzione congiunta.

In questi ambiti, l’open source può contribuire alla verificabilità, al riutilizzo e alla ricerca indipendente.

Allo stesso tempo, restano necessarie la buona governance, la gestione dei dati, la sicurezza e la valutazione giuridica. L’open source è un requisito fondamentale per alcune forme di controllo, non una soluzione totale.

Parti dalla licenza: è consentito l’utilizzo che hai in mente? Quindi guarda la manutenzione, la documentazione, la qualità e le dipendenze.

Un pacchetto popolare non è automaticamente adatto. La scelta deve adattarsi allo scopo, al rischio e alla gestione.

Controlla la licenza, l’origine, lo stato di manutenzione, le vulnerabilità e la necessità. Chiedi anche se la parte è davvero necessaria.

Ogni dipendenza aggiunge diritti, obblighi e gestione.

Registra quali componenti vengono utilizzati, quale versione, quale licenza e in cosa è incluso il componente.

Assicurati inoltre che sia chiaro chi è responsabile degli aggiornamenti e del rispetto delle condizioni.

Utilizza una combinazione di strumenti di registrazione, controllo periodico e scansione delle dipendenze.

Ancora più importante: concordare chi esaminerà le notifiche e chi deciderà su aggiornamenti o sostituzioni.

Esistono molti strumenti che mappano dipendenze, licenze e vulnerabilità. Gli esempi includono scanner nelle piattaforme di sviluppo, gestori di pacchetti e strumenti di conformità specializzati.

Lo strumento è solo uno strumento. L’organizzazione deve ancora fare delle scelte e organizzare il follow-up.

Si prega di leggere prima le istruzioni per il contributo e la licenza. Descrivi chiaramente cosa vuoi migliorare e perché.

Un buon contributo può essere il codice, ma anche la documentazione, il test, la traduzione o un problema chiaramente descritto.

Ciò ha senso se vuoi che altri possano utilizzare, monitorare, condividere e modificare il lavoro.

Fai questa scelta consapevolmente: determina lo scopo, la licenza, la manutenzione, la governance e cosa ti aspetti o non ti aspetti dai contributi.

Per prima cosa decidi cosa vuoi consentire e proteggere. Se desideri un’ampia riusabilità, guarda le licenze permissive. Se vuoi che la libertà venga trasmessa, guarda il copyleft.

Utilizza preferibilmente licenze esistenti e conosciute invece di scrivere tu stesso il testo.

Fornire documentazione chiara, un modo amichevole per porre domande, un processo decisionale chiaro e aspettative realistiche.

Una comunità non si crea semplicemente mettendo il codice online. Richiede attenzione, fiducia e mantenimento.

Dividere diritti e responsabilità. Documenta i processi, rendi portabili le versioni e concedi diritti di gestione a più persone fidate.

Ciò aumenta la continuità e rende il progetto meno vulnerabile.

Un Open Source Program Office, spesso chiamato OSPO, è un team o una funzione che organizza l’uso e i contributi dell’open source all’interno di un’organizzazione.

Aiuta con politiche, licenze, collaborazione, comunità e pubblicazione responsabile.

Come minimo, sono necessarie policy per l’utilizzo, il contributo, la pubblicazione, il controllo delle licenze e il monitoraggio della sicurezza.

La politica deve essere pratica: le persone devono sapere cosa è consentito, quando chiedere consigli e chi decide.

Spiegare in un linguaggio semplice cosa significano copyright, licenze e obblighi. Usa esempi tratti dal tuo lavoro.

La formazione non deve essere solo legale, ma anche pratica: cosa registri, cosa controlli e dove chiedi aiuto?

Tutto, a seconda della scelta. Il diritto esamina i diritti e gli obblighi. La sicurezza esamina le vulnerabilità e la gestione. L’ingegneria guarda alla qualità e all’applicazione. L’approvvigionamento esamina contratti e fornitori.

L’open source spesso influisce su più responsabilità contemporaneamente.

Assicurarsi che sia chiaro quali parti sono state utilizzate, quali licenze si applicano, quali controlli sono stati effettuati e quali decisioni sono state prese.

Audit significa principalmente: essere in grado di spiegare in seguito cosa è successo e perché.

Includere consapevolmente l’open source nei requisiti, nei criteri di valutazione e nelle condizioni contrattuali. Non chiedersi solo di prodotto, ma anche di diritti, portabilità e gestione.

In questo modo eviterai che l’apertura rimanga solo un desiderio e non finisca nell’incarico.

Considera il supporto come un supplemento ai diritti open source. Il contratto può contenere accordi su tempi di risposta, aggiornamenti, responsabilità, hosting o gestione.

Il software può essere aperto, mentre il supporto è professionale e a pagamento.

Non guardare solo ai costi di licenza. Includere anche gestione, supporto, formazione, integrazione, migrazione, conformità e manutenzione.

L’open source può essere più economico, ma il vero valore spesso risiede nel controllo, nella flessibilità e nella minore dipendenza.

Trattare l’open source come parte della normale gestione del rischio. Considera licenze, manutenzione, sicurezza, dipendenze e continuità.

Il rischio non è che qualcosa sia open source, ma che l’utilizzo avvenga inconsciamente o incustodito.

Non limitarti a misurare i costi risparmiati. Guarda anche al riutilizzo, alla velocità, alla trasparenza, alla dipendenza evitata, alla collaborazione e alla qualità del controllo.

Un certo valore è finanziario, un altro valore è nell’autonomia e nella fiducia.

No. L’open source offre libertà importanti, ma non dice automaticamente nulla su tutte le scelte etiche riguardanti l’uso, l’impatto o la governance.

L’apertura può aiutare a consentire la discussione, il controllo e la responsabilità.

Non completamente. Le licenze open source consentono un ampio utilizzo e di solito non limitano lo scopo per cui qualcuno utilizza il lavoro.

Chi vuole limitare gli abusi finisce presto per andare oltre il classico open source e deve pensare ad altri mezzi legali o organizzativi.

Le licenze open source classiche non limitano le finalità di utilizzo. Danno diritti a tutti, anche se il creatore considera alcune applicazioni indesiderabili.

Esistono licenze con restrizioni d’uso etiche, ma generalmente non sono considerate open source in senso stretto.

L’open source dà ad altri il controllo sul proprio utilizzo: possono studiare, adattare e condividere. Il creatore originale rinuncia quindi ad un controllo esclusivo sulla distribuzione e sulla modifica.

Questo non è un errore, ma esattamente la scelta che rende speciale l’open source.

L’open source può supportare valori pubblici come la trasparenza, la verificabilità, il riutilizzo e l’indipendenza.

Ma i valori pubblici richiedono anche buon governo, accessibilità, sicurezza, finanziamenti e responsabilità.

Questo varia notevolmente in base al progetto. Alcune comunità sono aperte e disponibili, altre sono di difficile accesso o dipendono da reti informali.

L’inclusione richiede un’attenzione attiva al linguaggio, al comportamento, alla documentazione, al processo decisionale e alla partecipazione sicura.

Questa è una questione importante. Gran parte delle infrastrutture digitali sono ampiamente utilizzate, ma non sempre ampiamente finanziate.

L’open source ne rende possibile l’uso, ma la manutenzione richiede tempo, denaro e responsabilità da parte delle parti che dipendono da esso.

L’open source può diffondere potere perché gli utenti hanno più diritti rispetto al semplice acquisto di ciò che offre un fornitore. Possono farlo controllare, regolare o cambiare.

Ciò rafforza l’autonomia, ma solo se esistono conoscenza, capacità e governance per utilizzare tali diritti.

Una prevenzione completa di solito non è possibile nell’ambito dell’open source classico. Tuttavia, i progetti possono optare per licenze adeguate, governance, accordi commerciali e una cultura in cui i contributi siano normali.

Gli utenti possono anche assumersi la responsabilità restituendo manutenzione, denaro o conoscenze.

L’open source rimane importante per le infrastrutture digitali, il governo, l’istruzione, il cloud, l’intelligenza artificiale e la sicurezza. Il nucleo rimane legale: concedere i diritti di utilizzo, studio, condivisione e adattamento.

La grande sfida è la gestione sostenibile: garantire che i progetti aperti non siano solo utilizzati, ma anche mantenuti e gestiti in modo responsabile.

MIAUW sta per Methodology for Information Security Research with Audit Value. È un modo per condurre ricerche sulla sicurezza, come un pen test, in modo strutturato e verificabile.

L’obiettivo è che un’organizzazione non solo riceva un rapporto, ma possa anche dimostrare meglio cosa è stato ricercato, come è stato fatto e quali conclusioni ne derivano.

Ulteriori informazioni su MIAUW.

Molte indagini sulla sicurezza producono risultati utili, ma sono difficili da valutare a posteriori. A volte non è chiaro cosa rientrasse esattamente nell’ambito di applicazione, quali passaggi siano stati effettuati o quali prove supportino una conclusione.

MIAUW aiuta a registrare meglio questi componenti prima e durante la ricerca. Ciò rende la ricerca più utile per il recupero, la responsabilità e gli audit.

Ulteriori informazioni su MIAUW e in Cosa significa valore di audit?.

No. Un pen test è una forma di ricerca sulla sicurezza. MIAUW è una metodologia per strutturare, registrare e rendere tale ricerca più controllabile.

È quindi possibile eseguire un pen test secondo MIAUW, ma MIAUW è più ampio della semplice esecuzione di test tecnici.

Leggi anche Cos’è un test con la penna? e MIAUW.

Il valore dell’audit significa che un’indagine può essere adeguatamente valutata in seguito. Un revisore o un altro valutatore deve essere in grado di vedere cosa è stato concordato, cosa è stato testato, quali prove ci sono e come sono state raggiunte le conclusioni.

Ciò rende un’indagine utile non solo per la tecnologia, ma anche per la governance, la conformità e la responsabilità.

Ulteriori informazioni su MIAUW e Che cos’è la relazione di un revisore presso MIAUW?.

MIAUW è destinato a clienti, penetration tester, revisori, specialisti di conformità e amministratori.

Il cliente acquisisce un maggiore controllo sulla ricerca. Il ricercatore riceve una struttura chiara. Il revisore riceve informazioni più verificabili. Gli amministratori acquisiscono maggiore certezza su ciò che un rapporto dice e non dice.

Ulteriori informazioni su MIAUW.

No. Nessuna metodologia può garantire che un sistema sia sicuro.

MIAUW aiuta a condurre meglio la ricerca sulla sicurezza, a documentarla meglio e a utilizzarla meglio per il miglioramento. Aumenta quindi la qualità e l’utilità della ricerca, ma non sostituisce una buona gestione della sicurezza.

Leggi anche Qual è l’aspetto centrale di uno studio MIAUW?.

L’attenzione si concentra su accordi chiari, una portata chiara, prove imitabili, risultati riproducibili e relazioni utili per diversi gruppi target.

Un team tecnico vuole i dettagli per risolvere i problemi. Il management vuole sapere cosa significa il rischio. Un revisore vuole essere in grado di valutare se l’indagine è stata condotta con attenzione.

Ulteriori informazioni su MIAUW.

Scopo significa: cosa è e cosa non è parte della ricerca. Pensa a sistemi, domini, applicazioni, account, reti, periodi e domande di ricerca.

Un ambito chiaro evita malintesi. Senza ambito è difficile dire in seguito se qualcosa è stato deliberatamente lasciato nascosto o accidentalmente non esaminato.

Vedi anche In che modo OpenKAT gestisce l’ambito e i permessi?.

Le prove rendono i risultati verificabili. Un rapporto non dovrebbe solo dire che qualcosa non va, ma anche mostrare su cosa si basa tale conclusione.

Le prove possono includere registri, schermate, output di comandi, dati di configurazione o altri record. Naturalmente, le informazioni sensibili devono essere gestite con cura.

Leggi anche Cosa significa sicurezza basata sull’evidenza?.

Un risultato è un problema, un rischio o un punto di attenzione identificato dalla ricerca.

Una buona scoperta descrive cosa è stato trovato, perché è importante, quali prove sono coinvolte, quale potrebbe essere l’impatto e quale misura aiuta a ridurre o risolvere il problema.

Leggi anche Qual è la differenza tra un rischio e una vulnerabilità?.

Una vulnerabilità è un punto debole. Un rischio riguarda ciò che quella debolezza può significare per l’organizzazione.

Una vulnerabilità in un sistema di test senza dati sensibili presenta spesso un rischio diverso rispetto alla stessa vulnerabilità in un sistema pubblico con dati personali. Quindi il contesto è importante.

Leggi anche Che cos’è una constatazione?.

No. Le grandi organizzazioni spesso hanno requisiti di audit e conformità più formali, ma anche le organizzazioni più piccole traggono vantaggio da accordi chiari, prove migliori e reporting utile.

MIAUW può effettivamente contribuire a rendere la ricerca sulla sicurezza più comprensibile e trasferibile.

Ulteriori informazioni su MIAUW.

La dichiarazione di un revisore può aiutare a dimostrare che un’indagine è stata condotta secondo gli accordi, senza che tutti i dettagli tecnici debbano essere ampiamente condivisi.

Ciò è utile quando un rapporto completo è troppo delicato per un’ampia distribuzione, ma un’organizzazione deve dimostrare che è stata condotta una ricerca seria e verificabile.

Leggi anche Se faccio un pentest con MIAUW devo renderlo pubblico?.

Un pen test, o penetration test completo, è un’indagine di sicurezza controllata. I ricercatori cercano di individuare le vulnerabilità prima che lo facciano i malintenzionati.

Un pen test non è un attacco casuale. Esistono accordi su ambito, autorizzazione, approccio, reporting e dovuta diligenza. I ricercatori utilizzano tecniche che possono essere utilizzate anche dagli aggressori, ma con l’obiettivo di migliorare la sicurezza.

Nella Metodologia per la ricerca sulla sicurezza delle informazioni con valore di audit (MIAUW), abbiamo ampiamente discusso una definizione guidata dal Sig. V.A. i Pous. Ciò ha portato a questa definizione:

‘Un’indagine offensiva sulla sicurezza che deve essere condotta dal nostro personale o da terzi, che comporta una ricerca controllata di vulnerabilità in una o più reti protette e sistemi informativi o parti di essi, che possono essere utilizzate per violare tali sistemi e/o che possono, senza intenzionalità o autonomamente, interrompere il trattamento dei dati dell’organizzazione sotto indagine o avere altrimenti conseguenze negative.’

Leggi anche Cos’è MIAUW?.

No, non è necessario. Lo scopo di MIAUW è mettere il cliente al primo posto. Se paghi per un rapporto, è logico che tu abbia il controllo sul prodotto che acquisti. Per questo motivo MIAUW dice qualcosa riguardo al fornitore: non può imporre al cliente restrizioni sulla distribuzione. È descritto così:

Non sono imposti vincoli al cliente in merito alla diffusione, pubblicazione o conservazione del report e dei documenti sottostanti. Sono esclusi da ciò i dati finanziari relativi allo svolgimento della ricerca, come tariffe orarie, prezzi e fatture.

L’obiettivo più grande è che con un pen test si possa anche dimostrare che le questioni importanti sono state organizzate correttamente. Ciò è difficile se non ti è consentito mostrare o fornire la ricerca ad altri. Non è necessario condividere le informazioni finanziarie sulla ricerca perché non dicono nulla sullo stato della sicurezza.

Il rapporto contiene troppe informazioni sensibili per poterlo condividere ampiamente? Allora la relazione di un revisore può aiutare. Ciò consente di dimostrare che lo studio è stato condotto e quale è stato il risultato principale, senza diffondere tutti i dettagli tecnici.

In breve: il cliente determina quale livello di informazioni viene condiviso con partner, regolatori o altri, senza essere ostacolato dal fornitore.

Leggi anche Che cos’è la relazione di un revisore presso MIAUW?.

CVSS 4.0 fornisce un metodo aperto e indipendente dal fornitore per acquisire le caratteristiche tecniche e la gravità di una vulnerabilità. Il vettore mostra anche quali valori e ipotesi hanno portato al punteggio. Ciò rende una valutazione più trasferibile e verificabile rispetto alla semplice etichetta “alta” o “critica”.

MIAUW utilizza questo linguaggio di misurazione comune per segnalare la gravità e la fondatezza dei risultati in modo imitabile. MIAUW non determina automaticamente se esiste una vulnerabilità e non prescrive una decisione di ripristino. Secondo la specifica ufficiale di FIRST, CVSS è un input per l’analisi del rischio, non l’analisi completa del rischio.

No. CVSS descrive la gravità tecnica di una vulnerabilità. Un rischio organizzativo comprende ad esempio anche la possibilità di un abuso, il valore e il funzionamento del sistema, le persone interessate, gli obblighi legali, i possibili danni e le misure di controllo esistenti.

FIRST quindi chiama CVSS un input per l’analisi del rischio. Fattori come danni finanziari, danni alla reputazione, numero di clienti interessati e requisiti legali sono coperti da espressamente al di fuori del CVSS. Un’organizzazione valuta questi fattori nella propria gestione del rischio.

SÌ. CVSS 4.0 include esplicitamente il contesto. Le metriche delle minacce descrivono l’attuale maturità dell’abuso. Le metriche ambientali elaborano l’ambiente di distribuzione concreto, comprese le misure di sicurezza esistenti, l’effettiva accessibilità, l’importanza richiesta di riservatezza, integrità e disponibilità, le caratteristiche tecniche modificate e le possibili conseguenze per la sicurezza umana.

Le metriche supplementari aggiungono ulteriore contesto come sicurezza, ripristino, automazione e impegno di ripristino. Non cambiano il numero CVSS, ma secondo Domande frequenti su CVSS 4.0 di FIRST possono influenzare la priorità locale.

Un CVSS-B pubblicato pubblicamente solitamente contiene solo le metriche di base. Ciò non equivale a dire che CVSS non ha contesto: il cliente completa le metriche ambientali e di minaccia per la propria situazione e quindi riceve un CVSS-BTE. FIRST consiglia questo arricchimento per un risultato più significativo nel proprio ambiente.

Il punteggio tecnico di base può essere lo stesso, ma non è necessario che lo sia anche il punteggio CVSS-BTE locale. Un ambiente di test isolato, una postazione di lavoro interna, un servizio di identità pubblica e un dispositivo critico per la sicurezza possono differire in termini di accessibilità, misure, protezione richiesta e conseguenze per altri sistemi o persone.

CVSS 4.0 può catturare tali differenze con le metriche di minaccia e ambientali. Anche la sicurezza umana può incidere direttamente sul punteggio delle Metriche Ambientali. Anche il contesto aggiuntivo può influenzare la classifica locale senza modificare il numero. Un sistema interno non riceve automaticamente un punteggio inferiore: ogni aggiustamento deve seguire proprietà dimostrabili dell’ambiente reale. Vedi i gruppi metrici e le regole di valutazione di FIRST.

SÌ. Un riscontro positivo allo scanner o il numero di versione corrispondente non dimostrano che il codice vulnerabile sia presente, accessibile o eseguibile. Verificare quindi innanzitutto il componente e la versione utilizzata, la configurazione, il percorso della chiamata ed eventuali accorgimenti. La ricerca sul codice sorgente, SBOM, VEX, analisi della configurazione e test dinamici possono fornire prove adeguate a riguardo.

Se il prodotto sembra non essere interessato, documentare questa non applicabilità con prove. Non attribuire artificialmente un punteggio CVSS basso a una vulnerabilità che non si applica. FIRST descrive inoltre in le domande frequenti su CVSS 4.0 che un fornitore dovrebbe rivalutare il punteggio per il prodotto concreto e può utilizzare VEX per comunicare l’applicabilità.

Un metodo uniforme offre a fornitori, ricercatori e acquirenti gli stessi concetti e un vettore leggibile dalla macchina. Ciò consente loro di scambiarsi valutazioni, verificare ipotesi e perfezionare il punteggio per il proprio ambiente. La ricerca sui dati sulle vulnerabilità mostra che valutazioni di gravità incoerenti possono ridurre notevolmente la qualità dell’ulteriore definizione delle priorità (Croft, Babar e Li, 2022).

Questo vantaggio non significa che ogni organizzazione debba utilizzare la stessa sequenza di ripristino. L’accordo significativo è: standardizzare i parametri, non la decisione. La minaccia locale, il contesto del sistema, la politica e l’accettazione del rischio rimangono decisivi.

Non nel senso di un modello empirico che prevede la probabilità di un abuso o il danno atteso. CVSS è una convenzione di misurazione standardizzata basata su definizioni tecniche e opinioni di esperti. Per la versione 4.0, milioni di possibili vettori sono stati raggruppati e classificati da esperti; PRIMA pubblica questo metodo nel manuale dell’utente.

Ci sono dei test, ma sono limitati. Il NIST ha esaminato la formula CVSS 3 contro le recensioni dei designer. Ciò supporta il funzionamento interno di tale formula, non la previsione di incidenti o danni e non automaticamente la versione 4.0. La ricerca trova anche differenze tra i valutatori umani. Il CVSS è quindi utile come metodo di misurazione trasparente e condiviso, non come certezza scientifica.

No. Un punteggio CVSS elevato significa che le conseguenze e le condizioni tecniche sono gravi a seconda del vettore scelto. Non esiste una probabilità calibrata che la vulnerabilità venga sfruttata entro un certo periodo di tempo. La ricerca mostra che dare priorità esclusivamente alle soglie CVSS può essere inefficace (Jacobs et al., 2020).

CVSS 4.0 può includere l’attuale maturità dell’exploit nelle metriche delle minacce. Ad esempio, EPSS può essere utilizzato per una stima di probabilità; sono rilevanti anche gli attacchi confermati e le informazioni sulle minacce proprietarie. Inoltre, queste fonti non sostituiscono la valutazione del rischio locale.

No. La politica determina, tra le altre cose, la propensione al rischio, le classi di sistema, le scadenze, le eccezioni, i responsabili e le condizioni per l’accettazione del rischio. Il CVSS può registrare in modo coerente la gravità tecnica, la minaccia attuale e i fattori ambientali, ma non prende una decisione amministrativa.

Nella gestione del rischio, l’organizzazione combina tali informazioni con l’applicabilità, l’impatto aziendale, la sicurezza, la privacy, gli obblighi legali e le misure disponibili. Decide quindi, ad esempio, di ripristinare, limitare, evitare, trasferire o accettare con motivazione. Il punteggio e il vettore forniscono la prova di tale decisione; non sostituiscono la politica, la decisione o la motivazione dichiarata.

Un ordine utile è:

1. verificare che la vulnerabilità si applichi al prodotto;
2. controllare il punteggio base e il vettore CVSS per quel prodotto;
3. aggiungere informazioni sulle minacce attuali e fattori ambientali reali;
4. includere contesto aggiuntivo, come sicurezza, recuperabilità e obblighi legali;
5. applicare la propria politica di priorità, trattamento e accettazione del rischio;
6. registrare la decisione e la motivazione.

Ciò non crea un elenco di riparazioni automatico, ma una decisione che può essere seguita. FIRST consiglia di utilizzare le metriche di minaccia e ambientali per un risultato più significativo e chiama il risultato un input per la tua vulnerabilità e la gestione del rischio.

OpenKAT è lo strumento aperto di analisi delle vulnerabilità. Si tratta di un software open source che aiuta le organizzazioni a mappare il proprio panorama digitale e a rendere visibili vulnerabilità, errori di configurazione e rischi.

OpenKAT è incentrato sull’intuizione: cosa abbiamo, cosa è visibile, cosa sta cambiando e con cosa dobbiamo fare qualcosa?

Ulteriori informazioni su OpenKAT.

OpenKAT aiuta a comprendere meglio il tuo digitale fuori e dentro. Raccoglie informazioni su sistemi, domini, software e impostazioni e le converte in informazioni utili.

In parole povere: OpenKAT aiuta a vedere dove si trovano porte, finestre e serrature digitali e quali di esse necessitano di attenzione.

Ulteriori informazioni su OpenKAT.

La superficie di attacco è tutto ciò che un utente malintenzionato potrebbe tentare di utilizzare per ottenere l’accesso o causare danni.

Pensa a siti web, server di posta, ambienti cloud, API, VPN, vecchi domini, ambienti di test dimenticati e servizi configurati in modo errato. Quanto meglio conosci quella superficie, tanto più mirata sarà la protezione che potrai fornire.

Leggi anche Perché è importante la visione continua?.

Gli ambienti digitali sono in continua evoluzione. Vengono aggiunti sistemi, aggiornato il software, modificate le impostazioni e scoperte nuove vulnerabilità.

Una scansione singola è quindi un’istantanea. La visione continua aiuta a vedere i cambiamenti e a rispondere più rapidamente quando qualcosa si deteriora o diventa nuovamente vulnerabile.

Leggi anche OpenKAT può mostrare i cambiamenti nel tempo?.

No. OpenKAT e il pen testing si completano a vicenda.

OpenKAT fornisce approfondimenti tecnici continui e può raccogliere molti segnali. Un pen test è un’indagine mirata da parte di persone, con contesto, creatività e profondità. OpenKAT può aiutare a indirizzare meglio i pen test e a monitorare meglio i risultati.

Leggi anche Cos’è un test con la penna? e OpenKAT.

No. Nessun prodotto di sicurezza trova tutto automaticamente.

OpenKAT aiuta a raccogliere e valutare molte informazioni in modo strutturato. Ma restano necessari una buona portata, interpretazione, gestione e follow-up. Human context remains important.

Leggi anche In che modo OpenKAT aiuta con la definizione delle priorità?.

In OpenKAT, un rogue è un piccolo compito di ricerca o scanner che raccoglie informazioni specifiche. Ad esempio, può controllare qualcosa su DNS, TLS, versioni del software o altre proprietà tecniche.

L’idea è modulare: tanti piccoli compiti insieme forniscono un quadro più ricco dell’ambiente digitale.

Leggi anche Cos’è la normalizzazione in OpenKAT?.

Una scoperta è un segnale che richiede attenzione. Potrebbe trattarsi di una vulnerabilità, ma anche di un’impostazione errata, di misure di sicurezza mancanti o di deviazione dalla policy.

Una scoperta non è sempre immediatamente un incidente. Si tratta principalmente di un motivo per valutare cosa significa e quale seguito è necessario.

Leggi anche In che modo OpenKAT aiuta con la definizione delle priorità?.

Sicurezza basata sull’evidenza significa che le conclusioni si basano su dati registrati, non solo su sensazioni o supposizioni vaghe.

OpenKAT aiuta salvando le osservazioni e collegandole ai risultati. Ciò rende più semplice vedere su cosa si basa una conclusione e come la situazione cambia nel tempo.

Leggi anche Perché le prove sono importanti in MIAUW?.

La conformità consiste nel dimostrare che si rispettano regole, standard o accordi. OpenKAT può collegare osservazioni tecniche a politiche o standard.

In questo modo risulta più chiaro quali accertamenti tecnici siano rilevanti anche dal punto di vista amministrativo o giuridico. Ciò aiuta con gli audit, il reporting e la definizione delle priorità.

Leggi anche OpenKAT può aiutare con NIS2?.

No. Gli specialisti della sicurezza hanno bisogno dei dettagli tecnici, ma OpenKAT è utile anche per amministratori, revisori, team di conformità e direttori.

Ogni ruolo guarda in modo diverso alla stessa realtà: dettagli tecnici per la risoluzione, panoramiche per la guida e prove per la responsabilità.

Ulteriori informazioni su OpenKAT.

SÌ. OpenKAT è open source e può essere utilizzato da solo. Ciò richiede conoscenze tecniche, gestione e un’attenta progettazione.

Alcune organizzazioni optano quindi per l’autogestione. Altre organizzazioni preferiscono lavorare con un partner per l’hosting, la progettazione, la gestione o il supporto.

Vedi anche Partner e OpenKAT.

OpenKAT è uno strumento di sicurezza e dovrebbe essere usato con attenzione. La scansione viene eseguita solo nell’ambito concordato e con il permesso.

I risultati possono essere sensibili perché dicono qualcosa sulle vulnerabilità e sulle istituzioni. Quindi proteggi bene quelle informazioni e consenti l’accesso solo alle persone che ne hanno bisogno.

Leggi anche In che modo OpenKAT gestisce la privacy?.

OpenKAT funziona con oggetti che possono essere esaminati. Questo potrebbe essere, ad esempio, un nome di dominio, un indirizzo IP, un sito web, un server, un certificato o un altro componente tecnico.

Registrando separatamente tali oggetti, OpenKAT può stabilire relazioni: quale sito web appartiene a quale dominio, quale certificato appartiene a quale servizio e quale risultato appartiene a quale componente.

Ulteriori informazioni su OpenKAT.

Gli scanner spesso producono risultati approssimativi. Normalizzare significa convertire l’output in dati che OpenKAT può comprendere e confrontare in modo fisso.

Questo è importante perché OpenKAT vuole combinare informazioni provenienti da diverse fonti. Solo quando i dati sono ben strutturati è possibile collegarli a oggetti, risultati, standard e tempistiche.

Leggi anche Cosa significa sicurezza basata sull’evidenza?.

Uno scanner di vulnerabilità solitamente cerca vulnerabilità tecniche specifiche. OpenKAT è più ampio: può combinare dati provenienti da più fonti, stabilire relazioni, mostrare cambiamenti nel tempo e collegare i risultati a politiche o standard.

OpenKAT può quindi utilizzare scanner, ma è esso stesso principalmente una piattaforma per riunire osservazioni, contesto e follow-up.

Ulteriori informazioni su OpenKAT.

OpenKAT è destinato alla ricerca nell’ambito di un ambito concordato. Quindi esegui la scansione solo dei sistemi per i quali hai il permesso e per i quali è chiaro cosa può essere esaminato.

Ciò è importante per ragioni legali, tecniche e organizzative. La ricerca sulla sicurezza senza un ambito chiaro può causare rischi e danneggiare la fiducia.

Vedi anche Qual è lo scopo di un’indagine MIAUW?.

SÌ. Un’idea importante alla base di OpenKAT è che non vuoi solo un’istantanea, vuoi anche vedere come sta cambiando la situazione.

Ciò aiuta con domande come: un problema è stato risolto, si è ripresentato, è emerso qualcosa di nuovo e la situazione della sicurezza sta migliorando o peggiorando?

Leggi anche Perché è importante la visione continua?.

Non tutte le scoperte hanno la stessa urgenza. Un problema tecnico su un sistema di test non importante è spesso meno grave dello stesso problema su un sistema pubblico con dati sensibili.

OpenKAT aiuta collegando i segnali tecnici al contesto, alla politica e agli standard. Ciò consente a un’organizzazione di determinare meglio cosa deve essere affrontato per primo.

Leggi anche In che modo OpenKAT aiuta a garantire la conformità?.

OpenKAT può aiutare con il lato pratico della resilienza digitale dimostrabile: acquisire informazioni su sistemi, vulnerabilità, configurazioni errate e cambiamenti nel tempo.

NIS2 non riguarda solo la tecnologia, ma anche la governance, i rischi e la dimostrabilità. OpenKAT può fornire supporto tecnico per questo, ma non sostituisce un programma NIS2 completo.

Leggi anche In che modo OpenKAT aiuta a garantire la conformità?.

OpenKAT esamina principalmente dati tecnici, ma i risultati possono essere sensibili. Un rapporto su vulnerabilità o errori di configurazione può essere utilizzato in modo improprio se finisce nel posto sbagliato.

Ecco perché è importante limitare l’accesso, proteggere adeguatamente i risultati ed eseguire la scansione solo in un ambito chiaro.

Leggi anche politica sulla privacy di questo sito e OpenKAT è sicuro da usare?.

I risultati delle singole scansioni sono spesso difficili da interpretare. Le relazioni chiariscono come sono correlati i componenti: quale dominio appartiene a quale sito web, quale servizio viene eseguito su quale sistema e quale risultato appartiene a quale oggetto.

Queste relazioni rendono OpenKAT più di un elenco di notifiche. Diventa un modello dell’ambiente digitale che aiuta a comprendere meglio le cause, l’impatto e il seguito.

Ulteriori informazioni su OpenKAT.

SÌ. OpenKAT è interessante perché può combinare informazioni provenienti da diverse fonti. Considera scanner, fonti di dati esterne, controlli di configurazione e attività di ricerca personali.

L’obiettivo non è sostituire tutti gli strumenti, ma riunire meglio i risultati e renderli utili per l’analisi, il monitoraggio e la responsabilità.

Ulteriori informazioni su OpenKAT.

OciDeck è un programma di presentazione incentrato sui contenuti. Puoi creare diapositive da forme di diapositive, dati e testo chiari, invece di far scorrere manualmente gli oggetti su un’area di disegno.

Ulteriori informazioni su OciDeck.

OciDeck è destinato a persone che vedono le presentazioni come portatrici di conoscenza. Pensa a formatori, ricercatori, professionisti della sicurezza, sviluppatori, revisori, responsabili politici e organizzazioni che desiderano mantenere il controllo delle proprie informazioni.

È particolarmente interessante quando sono importanti il ​​contenuto, il riutilizzo, la verificabilità e la condivisione sicura.

Ulteriori informazioni su OciDeck e Caratteristiche di OciDeck.

Molti software di presentazione iniziano con una tela bianca. Trascini caselle di testo, immagini e forme in posizione.

OciDeck inizia dal contenuto. Scegli il tipo di diapositiva, inserisci il contenuto e lascia che la presentazione nasca da essa. Ciò semplifica il controllo, il riutilizzo e l’esportazione delle diapositive.

Leggi anche Perché Marp è importante per OciDeck.

Marp è un modo per creare presentazioni con Markdown. Markdown è una semplice notazione di testo.

Marp è importante per OciDeck perché significa che la presentazione rimane testo semplice. Ciò rende le modifiche controllabili e garantisce che il contenuto non sia bloccato in un formato di file chiuso.

Ulteriori informazioni su Perché Marp è importante per OciDeck.

Non necessariamente. OciDeck offre editor strutturati per tipo di diapositiva. Quindi puoi lavorare senza scrivere sempre Markdown.

Il markdown è principalmente la base aperta per la presentazione. Chiunque conosca Markdown può trarne vantaggio, ma non è un requisito rigoroso per ogni utilizzo.

Leggi anche Cos’è Marp?.

Le presentazioni spesso contengono informazioni più sensibili di quanto si pensi: nomi, indirizzi e-mail, dettagli del cliente, token, screenshot, note del relatore o dettagli tecnici.

OciDeck aiuta a rendere tali informazioni visibili in anticipo, prima che una presentazione venga condivisa o esportata.

Ulteriori informazioni su Funzionalità di privacy in OciDeck.

OciWacht cerca localmente dati potenzialmente sensibili in una presentazione. Pensa a numeri di identificazione, indirizzi e-mail, numeri di telefono, token, chiavi o altri modelli sensibili.

Per ogni risultato, l’autore può scegliere cosa farne: accettare, contrassegnare o omettere dalla presentazione ed esportare.

Ulteriori informazioni su Funzionalità di privacy in OciDeck.

No, non per la normale elaborazione della presentazione. OciDeck web funziona nel browser: l’app Flutter web viene caricata dal server e poi modifica, anteprima live, OciWacht, esportazione in PDF/PPTX/HTML e builder CVSS avvengono client-side. Il contenuto del deck non viene inviato a un backend per essere elaborato.

Non sono integrati nemmeno telemetria o analytics. Il server di hosting di OciDeck non ha quindi visibilità applicativa sul tuo deck, sulle modifiche, sui risultati privacy o sulle esportazioni.

Ci sono però alcune sfumature. Come ogni webhost, il server può avere normali access log, per esempio indirizzo IP, orario, file richiesti e user-agent. Questo mostra che qualcuno ha caricato l’app, ma non cosa fa quella persona in OciDeck.

Esiste anche un fetch proxy opzionale per l’importazione da URL quando una fonte non consente l’accesso CORS. Solo quando apri un URL non-CORS tramite quel proxy, il server vede l’URL inserito e inoltra i byte.

Le altre connessioni in uscita sono avviate dall’utente e vanno verso destinazioni che scegli o configuri tu, come assistenza AI opzionale, WebDAV/Nextcloud, un database CVE, provisioning secmodule o un URL che importi tu stesso.

Se vuoi usare OciDeck nel browser, vai su ocideck.nl.

Ulteriori informazioni su Funzionalità di privacy in OciDeck.

No. Nessuna scansione trova tutto.

OciWacht è uno strumento per identificare prima i rischi e condividerli in modo più consapevole. L’autore rimane responsabile del contenuto e deve sempre pensare da solo nelle presentazioni sensibili.

Leggi anche Perché le funzionalità di privacy in OciDeck sono importanti?.

Non tutte le diapositive sono destinate a ogni pubblico. OciDeck può aiutare a determinare per presentazione e per diapositiva quanto ampiamente le informazioni possono essere condivise.

OciDeck può quindi aiutare a evitare che una diapositiva interna finisca accidentalmente in una presentazione o esportazione più ampia.

Ulteriori informazioni su Condividi al giusto livello.

TLP sta per Traffic Light Protocol. È un sistema di colori per indicare quanto sono riservate le informazioni e con chi tali informazioni possono essere condivise.

Non è necessario conoscere l’abbreviazione per comprendere il principio. La domanda pratica è: chi è autorizzato a vedere queste informazioni?

Ulteriori informazioni su Condividi al giusto livello.

SÌ. I grafici in OciDeck rimangono collegati ai dati. Ciò li rende più controllabili e meno dipendenti dagli screenshot o dalle immagini create manualmente.

Ciò è utile per ricerche, report, dashboard e presentazioni in cui le cifre devono rimanere corrette.

Ulteriori informazioni su Caratteristiche di OciDeck.

SÌ. Le liste di controllo possono essere spuntate durante la presentazione.

Ciò è utile per corsi di formazione, workshop, dimostrazioni, revisioni della sicurezza e rapporti in cui i progressi devono essere visibili. La checklist diventa quindi parte della storia e non qualcosa in aggiunta alla presentazione.

Ulteriori informazioni su Caratteristiche di OciDeck.

SÌ. OciDeck si concentra sul lavorare da un’unica fonte e sull’esportazione in formati utilizzabili come PDF, PPTX e HTML offline autonomo.

Il vantaggio è che lo stesso contenuto può essere utilizzato per scopi diversi, senza dover costruire manualmente ogni volta nuove copie.

Ulteriori informazioni su Caratteristiche di OciDeck.

SÌ. OciDeck è open source. Il codice sorgente è in Forgejo:

https://pawprint.vigilis.online/LibreKAT/OciDeck

Leggi anche OciDeck.

Le forme delle diapositive sono tipi fissi di diapositive, ad esempio titolo, elenco, tabella, grafico, esempio di codice, domanda, sequenza temporale o dashboard.

Lavorando con le forme delle diapositive, il creatore deve scorrere meno manualmente. Il contenuto è centrale e OciDeck può visualizzare, controllare ed esportare tale contenuto in modo più coerente.

Ulteriori informazioni su Caratteristiche di OciDeck.

SÌ. OciDeck supporta diapositive con codice sorgente ed evidenziazione della sintassi. Il codice rimane testo reale anziché uno screenshot.

Ciò è utile per presentazioni tecniche, corsi di formazione e rapporti sulla sicurezza in cui il codice deve rimanere leggibile e verificabile.

Ulteriori informazioni su Caratteristiche di OciDeck.

SÌ. OciDeck può utilizzare diapositive Markdown gratuite, inclusi diagrammi Sirena e matematica LaTeX.

Ciò significa che i grafici e le formule possono essere salvati come contenuto di origine, anziché come un’immagine separata difficile da modificare in seguito.

Ulteriori informazioni su che rende possibile Marp Markdown.

La modalità Markdown è destinata agli utenti che desiderano lavorare direttamente nell’origine testo di un mazzo. Ciò può essere utile per la ricerca e la sostituzione, modifiche rapide al testo o controlli tecnici.

Non è sempre necessario utilizzare la modalità Markdown. Gli editor strutturati rimangono lì per coloro che preferiscono lavorare per diapositiva.

Leggi anche Cos’è Marp?.

OciDeck include un modulo di test della penna MIAUW opzionale. Questo modulo è destinato ai report secondo la Metodologia per la ricerca sulla sicurezza delle informazioni con valore di audit.

Pensa a trovare diapositive, riepiloghi, liste di controllo, panoramiche dell’ambito e supporto per la reportistica. Il modulo è disattivato per impostazione predefinita ed è destinato a situazioni in cui MIAUW è davvero rilevante.

Ulteriori informazioni su Caratteristiche di OciDeck e Cos’è MIAUW?.

L’esportazione HTML offline significa che una presentazione può essere trasportata o condivisa come versione HTML autonoma, senza la necessità di accedere alla rete durante la visualizzazione.

Ciò è utile per corsi di formazione, dimostrazioni e ambienti in cui non vuoi dipendere da presentazioni cloud o servizi esterni.

Ulteriori informazioni su Caratteristiche di OciDeck.

SÌ. OciDeck supporta la presentazione con, tra le altre cose, visualizzazione a schermo intero, navigazione tramite tastiera, timer, note, modalità prova e presentatore a doppio schermo.

Ciò rende OciDeck non solo un editor, ma anche uno strumento per fare presentazioni.

Ulteriori informazioni su Caratteristiche di OciDeck.

SÌ. OciDeck può funzionare con note del relatore e note separate per i partecipanti.

Ciò è utile perché non è necessario che tutte le informazioni siano sulla diapositiva stessa. Un relatore potrebbe aver bisogno di contesto aggiuntivo, mentre i partecipanti hanno bisogno di un riassunto o di un riferimento accurato.

Ulteriori informazioni su Caratteristiche di OciDeck.

SÌ. OciDeck può utilizzare Nextcloud/WebDAV come fonte per i pacchetti OciDeck e i mazzi Marp Markdown.

Ciò è adatto alle organizzazioni che preferiscono mantenere i documenti sotto la propria gestione o nel proprio ambiente collaborativo.

Ulteriori informazioni su Caratteristiche di OciDeck.

OciDeck si concentra su un’interfaccia accessibile, inclusi controlli da tastiera, etichette per lettori di schermo, scala del testo e annunci di cambio diapositiva.

L’accessibilità riguarda anche la struttura. Poiché le diapositive sono costituite da contenuti reali, è più facile mantenere tali contenuti comprensibili e verificabili.

Ulteriori informazioni su Caratteristiche di OciDeck.

Stai utilizzando Birra fatta in casa? Quindi esegui questi due comandi. Il primo punta Homebrew alla nostra fucina, il secondo installa OciDeck:

brew tap librekat/ocideck https://pawprint.vigilis.online/LibreKAT/homebrew-ocideck.git
brew install --cask librekat/ocideck/ocideck

La riga dell’indirizzo ne fa davvero parte. Se lo lasci fuori, Homebrew cercherà GitHub e non troverà nulla.

Questo è il percorso canonico: sia la ricetta che l’app provengono dalla nostra fucina. Se la fucina è temporaneamente non disponibile, il mirror GitHub è la copia di backup. Questo viene fatto in un comando, perché la forma abbreviata di Homebrew per definizione punta a GitHub:

brew install --cask brennodewinter/ocideck/ocideck

Qualunque sia l’installazione, Homebrew estrae la versione direttamente dalla nostra fucina e controlla automaticamente il checksum. L’app è firmata con un ID sviluppatore Apple e autenticata da Apple, quindi si apre con un semplice doppio clic.

Per aggiornare a una versione successiva, esegui:

brew upgrade --cask ocideck

La cask è solo un riferimento alla stessa versione firmata e autenticata; Homebrew non ospita l’app e non si aggiunge alcun intermediario. Homebrew Cask esiste solo per macOS: su Windows e Linux scarichi OciDeck direttamente.

Preferisci senza Homebrew? Allora scarica OciDeck direttamente dalla pagina di OciDeck. Lì trovi anche, per ciascuna piattaforma, come aprire e verificare il download.