SpaceX’s Starship is the most powerful launch system ever built, dwarfing even the mighty Saturn V both in terms of mass and total thrust. The scale of the vehicle is such that concerns have been raised about the impact each launch of the megarocket may have on the local environment. Which is why a team from Brigham Young University measured the sound produced during Starship’s fifth test flight and compared it to other launch vehicles.

Published in JASA Express Letters, the paper explains the team’s methodology for measuring the sound of a Starship launch at distances ranging from 10 to 35 kilometers (6 to 22 miles). Interestingly, measurements were also made of the Super Heavy booster as it returned to the launch pad and was ultimately caught — which included several sonic booms as well as the sound of the engines during the landing maneuver.

Sounds were measured at eight different locations.
The paper goes into considerable detail on how the sound produced Starship’s launch and recovery propagate, but the short version is that it’s just as incredibly loud as you’d imagine. Even at a distance of 10 km, the roar of the 33 Raptor engines at ignition came in at approximately 105 dBA — which the paper compares to a rock concert or chainsaw. Double that distance to 20 km, and the launch is still about as loud as a table saw. On the way back in, the sonic boom from the falling Super Heavy booster was enough to set off car alarms at 10 km from the launch pad, which the paper says comes out to a roughly 50% increase in loudness over the Concorde zooming by.

OK, so it’s loud. But how does it compare with other rockets? Running the numbers, the paper estimates that the noise produced during a Starship launch is at least ten times greater than that of the Falcon 9. Of course, this isn’t hugely surprising given the vastly different scales of the two vehicles. A somewhat closer comparison would be with the Space Launch System (SLS); the data indicates Starship is between four and six times as loud as NASA’s homegrown super heavy-lift rocket.

That last bit is probably the most surprising fact uncovered by this research. While Starship is the larger and more powerful of the two launch vehicles, the SLS is still putting out around half the total energy at liftoff. So shouldn’t Starship only be twice as loud? To try and explain this dependency, the paper points to an earlier study done by two of the same authors which compared the SLS with the Saturn V. In that paper, it was theorized that the arrangement of rocket nozzles on the bottom of the booster may play a part in the measured result.

hackaday.com/2024/11/21/measur…

A cura diManuel Roccon e Matteo Brandi

Se i criminali informatici non dormono mai, anche le normative sulle sicurezza informatica si muovono. Ormai la direttiva NIS2, recepita con il Decreto Legislativo 138 del 4 settembre 2024, si è messa in moto. Con la NIS2, la nuova direttiva europea per la sicurezza informatica, le aziende devono prendere sul serio la protezione dei dati e garantire la business continuity e rispetto alla NIS questa si estende anche alla loro supplychain.

Noi con elmetto e piccone (sicurezza first!) abbiamo scavato a fondo nella NIS2 per portarvi solo le pepite d’oro: quei punti che riteniamo fondamentali per proteggere la tua azienda contro i criminali informatici applicando la norma.

Caro lettore, due avvertimenti però:

1. Non troverai se la tua azienda ricade o meno nella direttiva, per quello c’è articolo di Sandro Sana
2. Non troverai una analisi degli obblighi di comunicazione e/o iscrizione a piattaforme varie
3. La NIS2 comprende anche la sicurezza fisica, i disastri ambientali e la mancanza di connettività e di energia elettrica.Mancano solo le cavallette. Noi ci siamo concentrati sul cyber. Per un gruppo elettrogeno, provvedi da solo.
4. Questa è la nostra interpretazione pratica della norma, con alcuni (piccoli e pochi ma importanti) esempi applicati realmente.

Per una applicazione pratica della NIS2, il pilastro principale è l’articolo è l’art.21, in particolare nel paragrafo 2, i cui concetti sono riportati anche nell’art.24 del decreto di recepimento (DLGS 138 del 4 Settembre 2024).

Abbiamo diviso questo articolo in due parti, in questo pezzo ci dedicheremo ad approfondire fino al punto e del art. 21 del NIS2.

Articolo 21 NIS2

eur-lex.europa.eu/legal-conten…

DLGS 138 art 24

gazzettaufficiale.it/eli/id/20…

Andiamo a vederli nel dettaglio:

Politiche di analisi dei rischi e di sicurezza dei sistemi informatici

Pensare che la protezione dei sistemi aziendali consista solo in firewall e antivirus potrebbe essere l’errore numero uno. Certo, fanno parte del quadro, ma non sono la soluzione completa. Le politiche di sicurezza informatica vanno molto più in profondità: devono valutare tutti i punti deboli di un’azienda e aggiornarsi costantemente.

Ad esempio, hai mai considerato che un dipendente non formato può diventare il miglior alleato dei criminali informatici? Basta una email di phishing cliccata senza pensarci troppo.

Inoltre quanto sono importanti i tuoi dati se finissero in mani sbagliate? Molto importanti anche i sistemi DLP che monitorano e mitigano la esfiltrazione dei dati, come il blocco delle chiavette o altri supporti di memorizzazione esterni così da evitare che vengano copiati dati e portati via e/o dimenticati in giro. Possono essere create anche regole per tipologia di documento o contenuto, in modo da bloccare questi quando vengono caricati anche in internet (es. un impiegato infedele che esegue upload su qualche drive online).

È per questo che l’analisi dei rischi è fondamentale: significa mappare ogni vulnerabilità, anticipare possibili scenari e sapere come reagire. Una buona analisi dei rischi non solo individua i punti critici ma ti aiuta a distribuire meglio le risorse per la difesa, concentrando l’attenzione dove serve di più.

Sembra un foschia impenetrabile? Un faro c’è e si chiama ISO 27001. L’ISO 27001 è il sistema di gestione della sicurezza informatica che mette ordine nella tua azienda, stabilendo standard chiari su come proteggere i dati e minimizzare i rischi di attacchi informatici. Con un approccio strutturato e una protezione continua, questo strumento potente ti aiuta a chiudere le porte ai criminali informatici.

link redhotcyber.com/post/cosa-si-i…

Gestione degli incidenti

Quando i criminali informatici colpiscono, non c’è tempo per tentennamenti o “la prossima volta andrà meglio”. La tua azienda è sotto attacco e senza un piano solido, rischi di vedere tutto andare in fumo. La gestione degli incidenti informatici è la tua unica ancora di salvezza: un set di strategie per reagire all’impatto devastante di attacchi, violazioni e perdite di dati.

Quanti piani servono? Fondamentalmente due: il Disaster Recovery Plan ed il Response Plan. Vediamoli.

Disaster Recovery Plan

Un disaster recovery plan non è solo un elenco di cose da fare, ma una strategia solida che garantisce che ogni dato, file o sistema critico sia protetto e ripristinabile.

Il piano deve prevedere eventi come:

• Attacchi da criminali informatici
• Guasti ai PC
• Incendi
• Alluvioni
• Furti
• Smarrimenti
• Terremoti
• Strategie di backup
• Mancanza di energia elettrica
• Mancanza di connettività ad internet

Un piano di ripristino da disastro deve avere come minimo queste informazioni:

1. Dati di contatto (chi devo chiamare)
2. Calcolo del danno stimato
3. Piano di recupero delle attività (come si risolve)
4. Piano di continuità aziendale (come si continua nel mentre)
5. Copie dei contratti ed accordi in essere
6. Piano di esercitazione (una volta scritto, va testato per farlo conoscere a tutti)
7. Lista dei sistemi e dati critici
8. Lista degli obblighi normativi da rispettare
9. Strategia comunicativa per i clienti e gli organi di stampa

Ovviamente non deve rimanere “lettera morta”, deve essere testato, corretto e ti devi assicurare tutti abbiamo compreso quale è il proprio ruolo.

La strategia comunicativa non è un punto da sottovalutare. In base a quello che si dice e come lo si comunica, la situazione, che già non è rosea, peggiora drammaticamente se lo si fa in modo errato. Avere comunicati studiati e preparati in anticipo, è il modo per non fare ulteriori danni.

Se ti serve un template lo trovi qui: https://www.microfocus.com/media/unspecified/disaster_recovery_planning_template_revised.pdf

Response Plan

Il response plan è il fratello del disaster recovery, ma più immediato, pronto all’azione. Serve quando un criminale informatico fa il primo passo e sei già nel pieno dell’incidente. Questo piano ha un obiettivo semplice: contenere, limitare i danni e, se possibile, bloccare l’attacco. I punti cardine sono:

1. Preparazione (preparation)
2. Identificazione (identification)
3. Contenimento (containment)
4. Eradicazione (eradication)
5. Recupero (recovery)
6. Lezione imparata (lesson learned)

Preparazione: tanto banale quanto fondamentale ma anche disattesa: essere preparati. Tutto qui.

Identificazione: riconoscere l’evento che dovrebbe essere classificato come incidente informatico.

Contenimento: isolare l’incidente e non consentire che si propaghi.

Eradicazione: risolvere il problema.

Ripristino: Riparare i sistemi compromessi, recuperare i dati e far ripartire le attività interrotte durante l’incidente.

Lezione appresa: È la parte più importante. È un documento dove si descrive l’accaduto, le procedure adottate, quello che ha funzionato ma soprattutto quello che non ha funzionato.

Se non tieni traccia del passato, è difficile pianificare il futuro.

Continuità operativa, gestione del backup, ripristino in caso di disastro e gestione delle crisi

Il punto focale della normativa è la continuità operativa. La norma prevede di minimizzare e ridurre il più possibile gli effetti di un Cyber attacco nella business continuity sia sulla tua attività che sulla catena di fornitura.

Cosa di più importante di un backup per ripristinare i dati in caso di compromissione? In particolare che sia certo di riuscire a ripristinarli in tempo accettabile, anzi mi fermerei prima di riuscire a ripristinarli.

E’ di fondamentale importanza valutare bene che i nostri backup siano robusti, affidabili e inattaccabili dalle minacce informatiche e possano essere ripristinati in tempi certi e accettabili compatibili con il proprio business e quello dei nostri processi aziendali.

Come ad esempio eseguire la regola del 3-2-1 in cui utilizzare 3 copie su 2 tipologie di supporto di diverso, di cui uno offsite, che di recente, con l’aiuto delle nuove tecnologie, si è evoluto in 3-2-1-1-0, aggiungendo l’immutabilità del dato. Lo 0 finale poi sta a significare che il sistema riesca a verificare che ci siano 0 errori, così da essere sicuro che quando servono i backup, siano usabili al 100%.

Ma la tecnologia non basta. Occorre una valutazione dei tempi di RTO e RPO per valutare bene la quantità accettabile di dati che possa essere persa dall’ultimo backup ed i tempi di ripristino che siano allineati con il business dell’azienda. Considerare inoltre di tenere un numero sufficientemente di backup per non rischiare che quelli creati non siano tutti compromessi da un infezione presente sui sistemi da molto tempo!

Molti non lo considerano, ma un backup incrementale tradizionale compresso e cifrato di qualche TB in una rete, potrebbe essere ripristinabile in 1 o 2 giornate, ma per comprendere bene questo tempo è necessario fare dei test di cui parleremo tra poco…

Parliamo dei famosi backup in cloud.

“Sono tranquillo, ho il backup in cloud inattaccabile”.

Ok tutto bello e magari anche vero, ma quanto tempo ci vuole per ripristinarlo con la tua linea da 10mb/s Tera e Tera di dati? Forse è meglio pensare di andare a prenderli in bicicletta… il tuo provider ti permette di far avere i dati in tempi accettabili? Una tecnologia iperconvergente (HCI), per esempio, impiegherebbe poche decine di minuti per ripristinare i dati nel virtual storage di un’intera organizzazione.

Quindi la domanda è: le tue tecnologie attuali sono corrette e soddisfacenti per soddisfare la tua business continuity? Smarcato il piano tecnico, inoltre, sono fondamentali le esercitazioni e i test di ripristino periodici per verificare nel piano pratico che tutto funzioni. E’ necessario scrivere un documento che evidenzi cosa fare in caso di disastro, cosa iniziare a ripristinare prima in accordo con il business.

Piano che dovrebbe essere già presente per i guasti hardware, da integrare per quelli cyber, inserendo anche quelli di natura cyber.

Il famoso Disaster Recovery Plan

Finché facciamo i test interni in totale tranquillità andrà sempre tutto bene, pensiamo a un Lunedì mattina quando scopriamo che i sistemi siano totalmente offline e oltre a ripristino dei sistemi dobbiamo coordinare i vari fornitori, i clienti, la comunicazione con l’esterno, i vari reparti per arrivare al DPO in conformità alle normative vigenti in caso di data breach.

Tanto per la legge di Murphy queste cose succedono o il Venerdì sera con la variante del Sabato oppure il Lunedì mattina. In queste situazioni senza una linea da adottare ben definita il panico è assicurato e così anche la capacità di prendere scelte lucide e ponderate è seriamente compromessa.

Per cui è necessario aver già definito i possibili scenari e tutti gli step per arrivare al ripristino totale, a istituire un unità di crisi con delle persone ben identificate assieme a procedure e checklist ben definite. Nulla deve essere lasciato al caso in queste situazioni. Ne abbiamo già parlato in “Gestione degli incidenti” ma…repetita juvant!

Sicurezza della catena di approvvigionamento, compresi aspetti relativi alla sicurezza riguardanti i rapporti tra ciascun soggetto e i suoi diretti fornitori o fornitori di servizi

Nella NIS 2 aspetti relativi alla sicurezza non riguardano solo soggetti direttamente impattati, ma si estende anche alla catena di fornitura. Una particolarità: il soggetto coinvolto è responsabile (pecuniariamente) di verificare che la NIS2 venga applicata nella sua catena (situazione un po’ complicata). In poche parole i fornitori di soggetti che entrano nella NIS2, devo aver messo in pratica le raccomandazioni principali per non impattare sui clienti in caso di incidente informatico.

Questo per due motivi. Il primo è che la compromissione di un fornitore possa impattare il suo diretto cliente e bloccarne operatività. Pensiamo a un fornitore IT con i dati di accesso dei clienti che viene compromesso: il passaggio ai propri clienti potrebbe essere molto rapido. L’altro aspetto riguarda la continuità operativa: un blocco di un fornitore potrebbe impattare sull’operatività dei propri clienti con conseguente blocco della produzione.

Possiamo avere un quadro più chiaro leggendo il regolamento di esecuzione della Commissione Europea della normativa al punto 5.

eur-lex.europa.eu/legal-conten…

Il testo spiega che dovresti accertarti di verificare che la tua catena di fornitura abbia adottato i requisiti minimi per difendere se stessa e i suoi clienti.

Quindi cosa posiamo fare?

Leggendo il decreto attuativo della Commissione Europea per la direttiva 2022/2555 (NIS2), che risulta ancora in consultazione pubblica, si intravede la possibilità che nel caso in cui il fornitore non riesca a dare garanzie sulla propria sicurezza informatica, questa possa essere gestita dal cliente stesso.

Vi è mai capitato di trovare delle vulnerabilità sui software che un fornitore vi sviluppa o fornisce? Succede spesso trovarsi di fronte a un muro di gomma quando chiediamo di riconoscere la vulnerabilità sistemarla oppure chiedere delle ulteriori misure di sicurezza non previste, esempio l’implementazione del MFA. Cose sicuramente che ai fornitori costa tempo e denaro implementare….

Quindi si pone l’opzione di revisione dei contratti con i fornitori (come suggerito dal punto 5.1.4) aggiungendo per esempio delle SLA sulla risoluzione di segnalazioni incluse anche penali o rescissione del contratto. Potrebbe essere necessario verificare il background di fornitori (hanno già subito databreach in passato?) e i suoi dipendenti oltre ad obblighi di far pervenire delle prove di audit, come penetration test o vulnerability assessment fatti regolarmente sui sistemi e software dei fornitori.

Un ulteriore approfondimento di Sandro Sana qui (redhotcyber.com/post/enisa-avv…)

Sicurezza dell’acquisizione, sviluppo e della manutenzione dei sistemi informatici e di rete, compresa la gestione delle vulnerabilità

Sicuramente il legislatore vuole software più sicuri. Come? I casi sono così tanti che non se ne può fare un elenco. Devono essere più sicuri.

Inoltre il decreto legislativo di recepimento il quale all’art.27 al comma 1 recita: “L’Autorità nazionale competente NIS,[…], può imporre ai soggetti essenziali e ai soggetti importanti di utilizzare categorie di prodotti TIC, servizi TIC e processi TIC, di cui, rispettivamente, all’articolo 2, comma 1, lettere ff), gg) e hh), sviluppati dal soggetto essenziale o importante o acquistati da terze parti, che siano certificati nell’ambito dei sistemi europei di certificazione della cybersicurezza di cui all’articolo 49 del regolamento (UE)”

Mentre il citato articolo 49 del regolamento UE 2019/881 dice: “Strategie efficaci in materia di cibersicurezza dovrebbero essere basate su buoni metodi di valutazione dei rischi, sia nel settore pubblico che in quello privato. I metodi di valutazione dei rischi sono utilizzati a diversi livelli, e non esiste una prassi comune per quanto riguarda le modalità per una loro applicazione efficiente. […]”

Ma allora??

Ci illumina il comma 2 dell’art.27 del decreto di recepimento: “Nelle more dell’adozione di pertinenti sistemi europei di certificazione della cybersicurezza di cui all’articolo 49 del regolamento (UE) 2019/881, l’Autorità nazionale competente NIS, secondo le modalita’ di cui all’articolo 40, comma 5, puo’ imporre ai soggetti essenziali e ai soggetti importanti di utilizzare categorie di prodotti TIC, servizi TIC e processi TIC, sviluppati dal soggetto essenziale o importante o acquistati da terze parti, che siano certificati nell’ambito di schemi di certificazione riconosciuti a livello nazionale o europeo.”

Qui ci viene in soccorso l’art. 58 della NIS2 che cita le ISO/IEC 30111 e ISO/IEC 29147 che “forniscono orientamenti sulla gestione delle vulnerabilità e sulla divulgazione delle vulnerabilità” mentre l’art.79 “[…] Le misure di gestione dei rischi di cibersicurezza dovrebbero pertanto affrontare anche la sicurezza fisica e dell’ambiente dei sistemi informatici e di rete includendo misure volte a proteggere detti sistemi da guasti del sistema, errori umani, azioni malevole o fenomeni naturali, in linea con le norme europee e internazionali, come quelle di cui alla serie ISO/IEC 27000”

Prima di aprire il portafoglio per l’acquisto di un software, ti dovrai sincerare sia su come viene gestita la sicurezza dello stesso che sulle clausole contrattuali per la gestione e la risoluzione delle vulnerabilità scoperte lungo il cammino. Per chi sviluppa software poi, diventa una pratica molto consigliabile quella di far fare i test di sicurezza a soggetti che non abbiano preso parte allo sviluppo: quasi sempre più guardi il codice e meno vedi. Un paio di occhi freschi spesso sono la soluzione.

Speriamo che fin qui questi spunti ti siano stati utili, nel prossimo articolo tratteremo i rimanenti punti del art. 21 f, g, h, i, j della direttiva.

L'articolo La NIS2 applicata con esempi pratici – Parte 1 proviene da il blog della sicurezza informatica.

Hydrogen! It’s a highly flammable gas that seems way too cool to be easy to come by. And yet, it’s actually trivial to make it out of water if you know how. [Maciej Nowak] has shown us how to do just that with his latest build.

The project in question is a simple hydrogen generator that relies on the electrolysis of water. Long story short, run a current through water and you can split H₂O molecules up and make H₂ and O₂ molecules instead. From water, you get both hydrogen to burn and the oxygen to burn it in! Even better, when you do burn the hydrogen, it combines with the oxygen to make water again! It’s all too perfect.

This particular hydrogen generator uses a series of acrylic tanks. Each is fitted with electrodes assembled from threaded rods to pass current through water. The tops of the tanks have barbed fittings which allow the gas produced to be plumbed off to another storage vessel for later use. The video shows us the construction of the generator, but we also get to see it in action—both in terms of generating gas from the water, and that gas later being used in some fun combustion experiments.

Pedants will point out this isn’t really just a hydrogen generator, because it’s generating oxygen too. Either way, it’s still cool. We’ve featured a few similar builds before as well.

youtube.com/embed/zlCg-qMO9ck?…

hackaday.com/2024/11/21/simple…

Gli Usa hanno investito miliardi per cercare di sviluppare quest'arma. Ora il patto nell'Alleanza Aukus potrebbe risultare decisivo.

The post Così l’Australia diventa fondamentale per lo sviluppo dei missili ipersonici Aukus appeared first on InsideOver.

A questo punto amici della Rogue Records vi attendiamo al varco.

Eh sì perché continuare a dare luce a prodotti di così alto lignaggio senza sbagliare un colpo sembra impresa davvero titanica. Certo, conosciamo la vostra competenza e la vostra passione, ma perdio fatelo uscire un 7" un po' inferiore alla media.
iyezine.com/the-woggles-anyway…
@Musica Agorà

The Woggles - Anyway the Wind / Slippin'out 7"

The Woggles - Anyway the Wind / Slippin'out 7" - The Woggles - Anyway the Wind / Slippin'out 7" se tale occasione ci sarà non si tratta comunque di questa perché la recente infornata di singoli offertaci dall'etichetta di Tolosa è nuovamente di una q…

^{Il Santo (In Your Eyes ezine)}

Buongiorno a tutti. 😊
Da quando, anni fa, ho abbandonato Facebook (e tutti gli altri social classici e tossici) e sono approdato nel Fediverso, tante cose sono cambiate nel mio modo di percepire il mondo social e il web in generale.
Per prima cosa ho aperto un account su Mastodon, poi ho conosciuto Friendica, Peertube e Pixelfed, ma ho sempre scritto quasi esclusivamente su Mastodon, a parte i video pubblicati su Peertube.
Stamattina ho pensato che sarebbe carino iniziare delle interazioni anche qui e cominciare a pubblicare pure su Pixelfed.
Questo messaggio è il primo passo del mio buon proposito.
Voi come siete giunti sul Fediverso? Quali sono state le motivazioni che vi hanno spinto a cambiare?

In lak'ech. 🙏
Marco