Server di posta “Secured by Design”

Aziende plurimiliardarie che investono milioni di euro in costose “soluzioni” (?) di Cybersecurity e consulenze erogate da fantomatici “esperti”, e poi immancabilmente si ritrovano a distanza di mesi o anni infettate da un ransomware o coinvolte in gravissimi incidenti informatici iniziati con una banale BEC.

Gente che blatera di Sicurezza Informatica senza conoscerne a fondo le reali basi ingegneristiche, sistemisti e tecnici ICT che venerano Active Directory come una panacea per tutti i mali, nonché Microsoft Exchange come “il” mail server per antonomasia…ma anche lì, incidenti su incidenti informatici dietro l’angolo.

La lungimiranza e la perspicacia, quel think outside of the box che ha permeato le vite di tanti acuti pensatori, nonché dei padri fondatori di Internet e di svariati progettisti, dovrebbe pervadere le riflessioni, le scelte progettuali e gli investimenti portati avanti anche dai manager e dai CISO italiani…o almeno, della maggior parte tra loro. Ma non è esattamente così.

Se davvero lo fosse, la maggior parte dei mail server ancor oggi utilizzati in Italia in ambienti Enterprise non continuerebbero ad essere basati su Microsoft Exchange piuttosto che su O365 (Microsoft Office 365)… sistemi su di cui più o meno periodicamente vengono scoperte devastanti vulnerabilità RCE (Remote Code Execution).

DoveCot, invece, è fatto di un’altra pasta: è un mail server Open Source ideato con la Sicurezza Informatica in testa; si definisce “Secured by Design”, ma puoi leggerlo come “Sicurizzato fin dalla progettazione”.

Un esempio emblematico: qualche anno fa l’ente Mozilla Open Source (non esattamente dei “bottegai” dell’informatica) ha commissionato un audit di sicurezza informatica su DoveCot, il primo audit pubblico del suo codice sorgente. Il team che ha eseguito l’audit è rimasto estremamente colpito dalla qualità del suo codice sorgente, dichiarando nero su bianco che “nonostante i molti sforzi e l’approccio onnicomprensivo, i penetration tester di Cure53 sono riusciti solo a confermare l’eccellente livello di sicurezza informatica di DoveCot. Più specificamente, sono stati riscontrati solo tre problemi di sicurezza nel codice, ma di scarsa gravità, traducendosi così in un risultato prestigioso per DoveCot, nonché una prova-provata del fatto che mantenere le aspettative di Cybersecurity è una priorità dello sviluppo e del funzionamento di questo software”. È possibile reperire il report dettagliato delle vulnerabilità riscontrate dal team dei penetration tester di Cure53 consultando questo URL.
Analogamente, a questo indirizzo è possibile leggere le più recenti vulnerabilità scoperte su DoveCot: provate a confrontare il numero di queste vulnerabilità (sia in quantità ma soprattutto in qualità/gravità!) con quelle scoperte su Microsoft Exchange, poi rifletteteci sopra chiedendovi se adottare software on-premises piuttosto che sistemi fruibili in SaaS per la posta elettronica sviluppati e distribuiti entrambi dalla Microsoft (società closed-source per antonomasia, anche omertosa quando si tratta dei propri databreach…leggetevi o rileggetevi, a tal proposito, dello scandalo riguardante il databreach di Microsoft Azure fatto emergere lo scorso anno dal senatore Ron Wyden e di questa recente inchiesta pubblicata sul Washington Post) sia ancora una scelta sensata e prudente.

Ransomfeed, la dashboard per monitorare le vittime dei ransomware

Grazie a una dashboard aggiornata periodicamente, con la piattaforma RansomFeed è possibile farsi un’idea delle rivendicazioni effettuate dalle cybergang che sfruttano attacchi informatici basati su ransomware. È possibile filtrare per paese e per altri parametri, venendo quindi a conoscenza anche dei nominativi delle aziende ed organizzazioni (anche italiane!) che ne sono rimaste vittime.

Esplorando la piattaforma, è possibile notare anche nomi di prestigiosi gruppi bancari…
Ransomfeed mette a disposizione gratuitamente un canale RSS con cui è possibile rimanere aggiornati sulle rivendicazioni pubbliche.

P.S.: A discapito di quanto pubblicizzano i media, ovviamente la piattaforma non elenca assolutamente tutte le vittime colpite, né storicamente né al presente… anche perché le vittime in essere potrebbero optare (come troppo spesso accade) di cedere al ricatto della cybergang di turno, pagando alla chetichella in Bitcoin pur di ottenere la chiave privata che occorre per il ripristino dei loro dati e sistemi (così da non finire né sulle pagine dei quotidiani, né appunto su portali come lo stesso RansomFeed, ma soprattutto per riprendere velocemente la loro operatività).

LOLBins CTI-Driven

Acronimo di Living-Off-the-Land Binaries Cyber Threat Intelligence, LOLBins CTI-Driven è un progetto ideato per supportare gli analisti InfoSec nella ricostruzione di come i binari LOLBin vengano utilizzati dagli attacker durante un’intrusione. Il software è in grado di ricostruire il workflow percorso dai processi generando e mostrando un formato grafico compatibile con le piattaforme TIP e con lo standard STIX.

Di recente, alla piattaforma è stato aggiunto il supporto per il processo regsvr32.exe:

Perché proprio regsvr32.exe? Poiché viene comunemente utilizzato (abusato!) dagli attacker per avviare l’esecuzione di codice malevolo tramite proxy. Il suo utilizzo malevolo coinvolge attività come:
– il bypass degli agent di sistemi XDR ed EDR
– l’esecuzione di scriptlet COM per scaricare dinamicamente backdoor da iniettare in memoria
– l’avvio di script dannosi
– l’utilizzo di librerie .dll malevole
– la distribuzione di payload
– l’avvio di script remoti in grado di rilasciare ed eseguire file
– la persistenza dei malware all’avvio dei sistema operativi
– l’esecuzione di file con estensione .sct

https://youtube.com/watch?v=xiu17NC61J4%3Fsi%3DbN1VijuYyekVxBKX

LOLBins CTI in azione

Link di approfondimento:
– Link1
– Link2
– Link3

SolarWinds…e l’ingenuità dei suoi clienti (anche italiani)

La Securities and Exchange Commission statunitense di recente ha rivolto accuse contro la nota Corporation di sviluppo software SolarWinds, con sede in Texas, e contro il suo responsabile della Cybersecurity, Timothy G. Brown, per frodi relative a rischi e vulnerabilità di sicurezza informatica taciute agli investitori e consumatori. La denuncia sostiene che, dall’offerta pubblica iniziale dell’ottobre 2018 e almeno fino al momento dell’annuncio nel dicembre 2020, SolarWinds sarebbe stata l’obiettivo di un massiccio attacco informatico durato quasi due anni, soprannominato “SUNBURST”: la Corporation e Brown hanno frodato gli investitori sopravvalutando SolarWinds in malafede, nascondendo anche ai consumatori finali dei loro software i reali rischi informatici a cui andavano incontro. Dai documenti depositati presso la SEC si evince che durante quel periodo SolarWinds avrebbe ingannato gli investitori rivelando solo rischi generici e ipotetici, in un momento storico in cui, invece, la società e Brown erano perfettamente consapevoli delle carenze informatiche strutturali nelle architetture ICT e nelle policy di sicurezza informatica dell’azienda (volutamente omesse nei rapporti con l’esterno), nonché dei rischi sempre più elevati che la Corporation stava affrontando all’epoca.

Come sostiene la denuncia, le dichiarazioni pubbliche di SolarWinds sulle pratiche di Cybersecurity interne – e soprattutto sui rischi dei possibili incidenti informatici – erano apertamente in contrasto con le loro analisi tecniche, inclusa una presentazione del 2018 preparata da un ingegnere e condivisa internamente anche con Brown, secondo cui le configurazioni per l’accesso remoto ai sistemi e ai servizi SolarWinds “non erano molto sicure” (per usare un sottile eufemismo!), e che “qualcuno che dovesse sfruttare la vulnerabilità può praticamente fare qualsiasi cosa prima che noi lo scopriamo, finché non sarà troppo tardi”, il che potrebbe portare a “gravi perdite sia di reputazione che finanziarie”. Allo stesso modo, come affermato nella denuncia della SEC, le presentazioni interne del 2018 e del 2019 di Brown evidenziavano, rispettivamente, che “l’attuale livello della Cybersecurity espone le nostre risorse critiche ad un potenziale stato molto vulnerabile“, e che “l’accesso privilegiato ai sistemi critici nonché ai dati è inappropriato“.
(puoi continuare l’approfondimento sul testo originale della denuncia seguendo questo link)

Perché continuare ad usare i prodotti di una software house che evidentemente, in un modo o nell’altro, continua ad ingannare i suoi clienti? Non bastano forse i pesanti databrech subiti da questa Corporation negli anni passati a mettere sul chi vive il consumatore?

…evidentemente no, se ancora molte aziende italiane (ma anche estere) continuano ad utilizzare (probabilmente nella più beata ingenuità…o forse a causa di una più preoccupante negligenza massificata?) software commerciali sviluppati da questa ormai ingannevole software house. Timore di cambiare fornitore o pigrizia per un ipotetico passaggio al mondo Open Source? Solo il tempo e gli incidenti informatici attuali e futuri dimostreranno ai clienti SolarWinds quanto costa (in termini di migliaia di dollari o di euro) la mancata valutazione di alternative, magari di alternative basate su software di monitoraggio Open Source: versatili, efficienti, spesso lowcost quando non del tutto FOSS, ma soprattutto più sicuri poiché liberamente ispezionabili dalle Community (Open Source —> codice aperto…oltre che libero!) nonché riprogrammabili dagli utenti, e spesso progettati con i principi ingegneristici della Security by Design in testa…e non con l’obiettivo di massimizzare a prescindere i profitti con la vendita di licenze di software consapevolmente buggato e insicuro.

Sistemi operativi “Secured By Design”

…forse il sistema operativo più sicuro mai realizzato?

HardenedBSD implementa soluzioni innovative di mitigazione degli exploit, nonché tecniche di Hardening del kernel derivate dalla community FreeBSD. L’approccio alla sicurezza Defence in Depth è sostanzialmente un approccio costituito da strati di controlli di sicurezza informatica contigui: per avere accesso, gli aggressori devono tassativamente superare ogni strato. HardenedBSD promette di adottare (così è indicato nero su bianco sul loro portale) un approccio olistico alla sicurezza informatica ingegnerizzando scrupolosamente il sistema operativo attraverso collaudate tecniche di Secure Coding, e implementando tecnologie di prevenzione e mitigazione degli exploit. “Lavoriamo con FreeBSD e su qualsiasi altro progetto basato su FreeBSD per includere le nostre innovazioni“. “Il nostro obiettivo principale è fornire una reimplementazione pulita delle parti pubblicamente documentate del patchset grsecurity per Linux“.

OPNsense ad esempio, un firewall Open Source che originariamente era basato su FreeBSD, ha integrato fin dal 2016 l’implementazione della funzionalità ASLR di HardenedBSD, e ha completato la migrazione a HardenedBSD il 31 gennaio 2019.

È interessante notare, infine, quanti pochi siano i CVE relativi ad HardenedBSD, e quanti innumerevoli, invece, siano quelli riferiti agli altri sistemi operativi: il confronto parla da solo.

Letture di approfondimento:
– link1 (una tabella comparativa delle feature di sicurezza informatica tra HardenedBSD e il resto del mondo BSD)
– link2 (manuale ufficiale del sistema operativo)
– link3 (tutte le feature di sicurezza informatica elencate punto per punto)
– link4 (soluzioni di firewalling in ambito bancario basate su HardenedBSD)
– link5 (elenco di mailing list)

Sabotatori professionali di reti wi-fi e LTE

Questo strano apparato è un esempio di jammer per reti Wi-Fi e cellulari, e può essere utilizzato per commettere crimini informatici. In che modo? Fa un eccellente lavoro bloccando praticamente ogni segnale che incontra nel suo raggio d’azione, tranne il 5G, ma ci sono modelli anche per quello. I jammer da decenni sono utilizzati nell’ambito della Guerra elettronica, ma possono altresì essere impiegati in prossimità di uffici ed edifici in cui le comunicazioni radio non sono desiderate (aree ad alta sicurezza, luoghi segreti di ritrovo diplomatici, ecc..) e da un po’ di tempo vengono utilizzati anche per commettere rapine. Qual è il nesso? Gran parte del mondo è diventato dipendente da webcam e telecamere di sicurezza wireless – diciamo eccessivamente, e i ladri lo sanno bene. Con meno di 1000€ questi dispositivi possono essere collocati in un veicolo, portati in prossimità dell’organizzazione o del luogo di residenza dell’obiettivo da depredare, e le telecamere andranno velocemente offline. I ladri faranno i loro sporchi affari e se ne andranno: in questi casi non hanno neanche necessità di conoscere anticipatamente la tecnologia usata dalle vittime, a loro basterà infatti usare un jammer…il che rende il tema Cybersecurity sempre più complesso.

Se non disponi di una rete di backup cablata , forse è il caso di investirci…o puoi sempre continuare a rischiare di perdere prove preziose a crimine avvenuto. Inoltre, personalmente mi accerterei di avere una scheda di memoria installata localmente nelle telecamere per garantire comunque la registrazione in presenza di indisponibilità di risorse Cloud: potresti non vivere mai questo scenario, ma almeno, in seguito potrai visionare la registrazione se mai dovesse disgraziatamente accadere.

C++ è il linguaggio C ad oggetti?

L’altra settimana, durante una chiacchierata con un mio studente, ho scoperto che all’università ha programmato in linguaggio C per superare un esame, e che il C++ non è stato oggetto delle lezioni… e che in fondo – mi ha confessato – in fin dei conti non gli è dispiaciuto, giacché – ipotizzava – “il C++ altro non è che il linguaggio C ad oggetti” (sue testuali parole).

Strana considerazione… o meglio, storia già sentita (e non solo da studenti, ma anche da alcuni ex colleghi di lavoro nonché da insegnanti d’informatica), ma nei fatti non è così: questo poteva essere vero fino al 1998 (anno in cui C++ è diventato “standard ANSI“), ossia 25 anni fa!

E mi rincresce ancor di più notare che tra i molti che sostengono questo, ci sono persone tutto sommato ancora giovani, segno che i loro docenti hanno insegnato loro pressappòco quello che loro stessi hanno a loro volta appreso 20 anni prima… ergo, sforzo per tenersi aggiornati: zero.

Ora, se erogate corsi di programmazione ma nel 2023 non sapete nulla di C++11 o di C++17, oppure pensate che siano solo “advanced concepts”, forse è il caso di studiare e aggiornarsi, oppure – in virtù dell’Onestà intellettuale che dovrebbe animare la didattica e l’insegnamento verso le generazioni di studenti presenti e future con cui ci si interfaccia, e che spesso pendono letteralmente dalle labbra di noi insegnanti e consulenti informatici – se non se ne ha voglia o tempo, è probabilmente il caso di dimettersi.

Tanto per cominciare, nelle specifiche del linguaggio C si parla di oggetti: quindi non sono entità sconosciute a tale linguaggio:
“Basic concepts – cppreference.com, Objects and alignment, Declarations and expressions create, destroy, access, and manipulate objects. Each object, function, and expression in C is associated with a type“

Confrontate la stessa pagina con quella relativa al C++: Object – cppreference.com

A questo punto prendete le specifiche del C++ reference – cppreference.com
E’ interessante osservare come più dei 3/4 di queste riguardano la libreria standard, e come l’intera libreria sia sviluppata in termini di un paradigma che non è basato sull’OOP, ma sulla programmazione generica.

Osserviamo anche che la libreria standard non è un “addendum”, ma una parte delle medesime specifiche tecniche del linguaggio: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/n4659.pdf, il che significa che non è possibile distribuire un compilatore privo della libreria standard chiamandolo banalmente C++.

Se poi osserviamo come le specifiche stesse del “core language” si sviluppano, noteremo (C++ language – cppreference.com) che la parte dedicata alle classi è solo una piccola parte dell’intera specifica.

Morale: che il linguaggio C non sia “orientato agli oggetti” è vero, ma sostenere a spada tratta che non li abbia è decisamente un bias cognitivo. Con più di 25 anni di storia, C++ e C sono ormai linguaggi profondamente diversi, con modalità e approcci allo sviluppo algoritmico del tutto differenti. Descrivere l’uno in termini dell’altro significa creare seri problemi alla preparazione dei futuri sviluppatori. E non sono il solo a sostenerlo:
– CppCon 2015: Kate Gregory “Stop Teaching C”
– CppCon 2017: Bjarne Stroustrup “Learning and Teaching Modern C++”

Il linguaggio C è utilizzato principalmente per realizzare i sistemi operativi e le loro utility, piuttosto che i programmi di controller, di driver e/o di sistemi embedded, viceversa, il linguaggio C++ è usato prevalentemente per scrivere le applicazioni native ospitate sui sistemi operativi: tra queste troviamo gli interpreti dei linguaggi dinamici e dei linguaggi a compilazione intermedia, i browser (Chrome, Firefox ecc..), i web server (Apache o similari), i motori dei grandi database nonché molti dei moderni sistemi di simulazione.

Non c’è comunque un confine netto, è più una questione di consuetudine. Benché i due linguaggi abbiano in comune alcuni costrutti sintattici, tuttavia i loro idiomi sono completamente diversi, e in genere non sono intercambiabili a piacere. Ma se preferite un confronto diretto, accedete a questa pagina, e facendo scorrere, noterete a colpo d’occhio cos’è il linguaggio C++ rispetto al C.

Lo spyware Pagasus colpisce ancora

Secondo una recente ricerca, lo smartphone di una giornalista russa nonché critica del Cremlino è stato infettato dallo spyware Pegasus.

Il famigerato software di spionaggio sviluppato dalla società israeliana NSO Group sarebbe stato installato sull’iPhone di Galina Timchenko (proprietaria del media indipendente russo Meduza) mentre si trovava a Berlino per una conferenza privata con altri giornalisti indipendenti russi che vivono in esilio. Secondo Access Now, una delle organizzazioni no-profit che ha indagato sull’hacking, si tratta del primo caso documentato di infezione da Pegasus che ha preso di mira un cittadino russo.

L’attacco è avvenuto a febbraio 2023, due settimane dopo che il governo russo ha messo fuori legge Meduza per la sua copertura critica del regime di Vladimir Putin e della guerra in Ucraina. Meduza ha trasferito il suo ufficio in Lettonia nel 2014, e da allora le persone che vivono in Russia possono accedere al suo portale web solo tramite connessioni in VPN. Meduza si presenta come uno dei pochi media russi indipendenti la cui copertura rimane libera dal controllo o dalla censura del Cremlino.

All’inizio di giugno, Timchenko ha ricevuto una notifica da Apple secondo cui il suo smartphone potrebbe essere stato un bersaglio di gruppi hacker finanziati dallo stato (APT). Timchenko non ha prestato molta attenzione a questo avvertimento poiché, secondo un rapporto pubblicato da Meduza, le autorità russe cercavano da anni di hackerare o interrompere l’infrastruttura della sua redazione, senza mai riuscirvi; tuttavia, Access Now, e Citizen Lab (un’organizzazione no-profit che difende i diritti digitali) dell’Università di Toronto hanno scoperto che l’iPhone di Timchenko è stato infettato dallo spyware Pegasus: questo malware può accedere a chiamate, messaggi e foto (e registrare il tutto, inviando il materiale su server remoti), attivare in maniera silente la fotocamera e il microfono del dispositivo, nonché tracciare la posizione dello smartphone.

“Non sono sicura di cosa abbiano potuto trovare sul mio dispositivo gli autori di Pegasus”, ha riferito Timchenko ad Access Now, e ancora, “Ho definito limiti molto rigidi tra la mia vita digitale e reale molto tempo fa”. Timchenko ha dichiarato di essere preoccupata soprattutto dalla possibilità che gli attacker possano aver avuto accesso alla sua lista contatti, il che sarebbe particolarmente rischioso se gli aggressori provenissero dalla Russia, “dove ogni cittadino può essere perseguitato per aver collaborato con organizzazioni indesiderate.”

Formalmente Pegasus viene venduto esclusivamente ad agenzie governative, ma i ricercatori di Citizen Lab hanno affermato di non essere riusciti a identificare chi si nascondesse dietro l’attacco, e NSO Group non ha risposto a una richiesta di commento. Secondo Citizen Lab, non ci sono prove che il governo russo utilizzi Pegasus, tuttavia, è possibile che paesi con legami con la Russia, come Azerbaigian, Kazakistan o Uzbekistan, abbiano violato Meduza per conto del Cremlino. Inoltre, i ricercatori hanno affermato che la Lettonia o la Germania potrebbero essere coinvolte, poiché sono rispettivamente il luogo in cui si trova Meduza, e dove il telefono di Timchenko è stato infettato.

Una precedente ricerca di Access Now ha rivelato che Pegasus è stato utilizzato per prendere di mira giornalisti, attivisti, funzionari governativi e civili armeni durante la guerra tra Armenia e Azerbaigian nella regione contesa del Nagorno-Karabakh. Secondo Citizen Lab non ci sono prove che l’Azerbaigian o il Kazakistan abbiano preso di mira persone in Germania, Lettonia o altri paesi dell’Unione Europa.

Dopo aver confermato l’infezione da Pegasus sullo smartphone di Timchenko, la direttrice di Meduza ha indetto una riunione di emergenza nei suoi uffici. “Eravamo tutti terrorizzati ma facevamo finta di niente”, ha dichiarato il capo della divisione tecnica di Meduza, il cui nome è tenuto segreto per ragioni di sicurezza. Meduza ha riferito che Timchenko ha cercato di “riderci sopra”, ma alla fine è scoppiata in lacrime. “Mi sentivo già come se fossi stata spogliata nuda nella piazza della città. Come se qualcuno mi avesse messo la mani in tasca. Come se in qualche modo fossi sporca. Volevo lavarmi le mani”, ha affermato.

Secondo i ricercatori è estremamente difficile impedire a Pegasus di infettare qualsiasi dispositivo preso di mira che esegua anche una singola applicazione vulnerabile, anche tra quelle preinstallate dalla Apple stessa. L’analisi di Citizen Lab sostiene che gli aggressori probabilmente sono entrati nell’iPhone di Timchenko attraverso un exploit zero-click in HomeKit e iMessage: un exploit zero-click consente ad un aggressore di compromettere un dispositivo o un sistema senza necessità alcuna di interagire con l’utente.

Secondo Meduza, Timchenko non aveva motivo di sospettare che ci fosse qualcosa che non andava nel suo iPhone, tranne nei momenti in cui lo smartphne risultava più caldo del solito, cosa che lei attribuiva (ingenuamente) al suo nuovo caricabatterie. Mercoledì, il caporedattore di Meduza, Ivan Kolpakov, ha rilasciato una dichiarazione in russo affermando che l’attacco hacker a Timchenko dimostra che i giornalisti russi in esilio “non possono sentirsi sicuri nemmeno in Europa”.

“I giornalisti indipendenti provenienti dalla Russia e da altre nazioni potrebbero sentirsi in trappola, affrontando la pressione sia dei loro stessi governi e dei loro sistemi di spionaggio, sia delle agenzie di Intelligence dei paesi in cui cercano rifugio”, ha detto Kolpakov. Secondo Kolpakov, Meduza e i suoi giornalisti sono costantemente minacciati da spie sia nel mondo fisico che nello spazio digitale. Sin dai primi giorni di Meduza, gli hacker sponsorizzati dallo stato russo l’hanno costantemente preso di mira con attacchi DDoS, e-mail di phishing e attacchi informatici mirati alla sua applicazione mobile.

“Ci intimidiscono e cercano di farci pensare solo alla nostra sicurezza e non al nostro lavoro”, ha dichiarato Kolpakov.

Hard disk saturo ha impedito la produzione di circa 13.000 veicoli

Toyota, uno dei più grandi produttori di auto al mondo, pochi giorni fa ha subito un fermo produzione non banale in 12 su 14 delle sue fabbriche in Giappone, fermo macchina che ha causato la mancata fabbricazione di circa 13.000 veicoli. Un attacco hacker andato a segno? Forse un ransomware? Nulla di tutto questo: è bastata una manutenzione programmata di alcuni database server, su cui tuttavia in quel momento non era disponibile sufficiente spazio disco. Questo tipo di incidenti informatici (contrariamente a quanto pensa il mainstream, la Cybersecurity non ha solo a che fare con gli hacker o i malware) dimostra la complessità delle connessioni tra i vari sistemi operativi e dispositivi, le diverse e numerose procedure operative da non trascurare, l’importanza fondamentale del monitoraggio dei sistemi e dei servizi ICT, la serietà con cui andrebbe effettuato il testing dei processi di backup e delle connessioni ridondate, le potenziali conseguenze sul piano tecnico ed economico di un incidente generato evidentemente dalla negligenza.

Investire in Sicurezza Informatica vuol dire anche investire in sistemi di monitoraggio, vuol dire prevenire potenziali incidenti informatici di questo e di altro tipo.
L’incidente della Toyota evidenzia almeno due aspetti su cui riflettere: il primo è che pur essendo una solida Industria 4.0 (come Toyota e altri colossi del settore), storici e banali incidenti informatici (banali nelle cause tecniche, ma non nelle conseguenze) di questo tipo posso comunque capitare se i sistemisti di turno non vigilano a sufficienza su allarmi e sensori; il secondo, è che pur investendo in costosi software commerciali (come verosimilmente avrà fatto Toyota) questi problemi possono comunque sorgere se il progettista, il sysadmin o il dirigente di turno non ha pensato bene (o addirittura non ha mai più di tanto immaginato!) agli scenari di fault (un sottoinsieme della Cyber threat modeling) e alle cause che possono generarli…ergo, è sempre l’ingegno dell’Uomo unito alla nostra attenzione che fa la differenza, è sempre la nostra capacità di immaginare le opportunità tecnologiche piuttosto che le potenziali minacce informatiche nei contesti più disparati che può fare la differenza tra un incidente informatico e una serena continuità di servizio, non lo strumento adottato in sé.

Nagios e CACTI sono due eccellenti software di monitoraggio sistemistico, molto utili a tal fine, peraltro Open Source. Certo non sono gli unici, ma ne garantisco la loro efficacia.

E tu, cosa utilizzi come sistema di monitoraggio, e cosa come sistema di backup? Li testi entrambi periodicamente? Ne effettui il monitoraggio H24 con procedure a prova di fault, magari anche con l’ausilio di un SIEM?

Syslog server Kiwi

Fantastico syslog server che nella sua versione gratuita consente di raccogliere e gestire messaggi syslog al massimo da 5 indirizzi IP sorgente: non è decisamente intuitivo il fatto che se non si provvede a editare la maschera in alto subito dopo l’installazione, i pacchetti syslog di tali client – pur se configurati a puntino come è successo a me – Windows o Linux che siano, non verranno visualizzati nella finestra principale del server mai e poi mai (tale problema non si manifesta nella versione a pagamento: in tal caso, infatti, basterà inserire solo l’IP 255.255.255.255 per autorizzare la raccolta di tutto il traffico syslog diretto al server).

Un video esplicativo delle sue tante funzionalità.